- 31 Aug, 2016 6 commits
-
-
bmeurer authored
The way we use FinishRegion for transitioning stores makes them eligible for elimination by TypedOptimization, which is unintended and removes the atomicity of the transitioning stores. This is a quickfix to ensure that we don't remove the FinishRegion nodes during TypedOptimization; the real fix is probably to have separate region operators for value (producing) regions (i.e. allocations) and for effect-only regions (i.e. transitioning stores). R=jarin@chromium.org BUG=v8:5303 Review-Url: https://codereview.chromium.org/2293023003 Cr-Commit-Position: refs/heads/master@{#39033}
-
bmeurer authored
If the type of a tracked field or element value is less precise than the advertised type of the field or element load, then we replace the load operation with a TypeGuard that guards the advertised type. R=jarin@chromium.org BUG=v8:5267 Review-Url: https://codereview.chromium.org/2295643002 Cr-Commit-Position: refs/heads/master@{#39032}
-
bmeurer authored
We (mis)used Type::Class to track stable field maps in the past. But that always more or less unsupport and wrong for various reasons, mostly because the class types do not really present static information and thus it is possible to violate fundamental assumptions of the type system (i.e. intersecting class types and other types produces "interesting" results). Now it is possible to finally nuke the class types completely and thus simplify (and ideally correctify) the type system further. Note to performance sheriff: We do expect to see some performance regressions from this change. This is because we do not yet have a sane replacement mechanism to track known field maps and utilize them during LoadElimination. This will be accomplished in a follow up CL. BUG=v8:5270,v8:5267 R=jarin@chromium.org Review-Url: https://codereview.chromium.org/2293343002 Cr-Commit-Position: refs/heads/master@{#39031}
-
adamk authored
This removes two bits of duplication: - Parsing of each AssignmentExpression, which previously was called first outside the loop and then inside the loop. - Parsing of arrow rest parameters, which previously was handled separately for the one-arg and N-arg cases. The only change in behavior is in a few error messages. Review-Url: https://codereview.chromium.org/2279363002 Cr-Commit-Position: refs/heads/master@{#39030}
-
adamk authored
Revert of Refactor object/class literal property name parsing (patchset #7 id:120001 of https://codereview.chromium.org/2278153004/ ) Reason for revert: Fails to reject "{*foo: 1}" as an object literal, found by the fuzzer: https://build.chromium.org/p/client.v8/builders/V8%20Fuzzer/builds/12315/steps/Fuzz%20on%20Ubuntu-12.04/logs/stdio Original issue's description: > Refactor object/class literal property name parsing > > This patch arranges that property names are parsed in a single pass, > reporting the name as well as the type of the property, instead of > parsing qualifiers like 'static' or 'get' initially as names and then > re-parsing. This change is easier to reason about, very slightly (4%) > faster in some cases (although slower in other, less common ones, though > this slowdown will be fixed in an upcoming patch), and is a prerequisite > for separating the parsing of object and class literal properties, which > will become increasingly important as ECMAScript adds more class features. > > Committed: https://crrev.com/6dd26c729584024e17a05a2a76b319d4aecdc138 > Cr-Commit-Position: refs/heads/master@{#39027} TBR=littledan@chromium.org,marja@chromium.org,bakkot@google.com # Skipping CQ checks because original CL landed less than 1 days ago. NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true Review-Url: https://codereview.chromium.org/2295743003 Cr-Commit-Position: refs/heads/master@{#39029}
-
mtrofin authored
Test ensuring globals are isolated between instances. Also added support for globals section to mjsunit's WebModuleBuilder as a prerequisite. BUG= Review-Url: https://codereview.chromium.org/2296993002 Cr-Commit-Position: refs/heads/master@{#39028}
-
- 30 Aug, 2016 34 commits
-
-
bakkot authored
This patch arranges that property names are parsed in a single pass, reporting the name as well as the type of the property, instead of parsing qualifiers like 'static' or 'get' initially as names and then re-parsing. This change is easier to reason about, very slightly (4%) faster in some cases (although slower in other, less common ones, though this slowdown will be fixed in an upcoming patch), and is a prerequisite for separating the parsing of object and class literal properties, which will become increasingly important as ECMAScript adds more class features. Review-Url: https://codereview.chromium.org/2278153004 Cr-Commit-Position: refs/heads/master@{#39027}
-
mvstanton authored
Increasingly, we avoid using the representation dimension of Type, and set it explicitly ourselves. BUG= Review-Url: https://codereview.chromium.org/2290233002 Cr-Commit-Position: refs/heads/master@{#39026}
-
bmeurer authored
When changing from Tagged to Float64 representation, it's not unlikely to see a HeapNumber (or if feedback says so, an Oddball), so we shouldn't penalize the code that deals with this case by marking it as deferred. R=mvstanton@chromium.org BUG=v8:5267 Review-Url: https://codereview.chromium.org/2295933003 Cr-Commit-Position: refs/heads/master@{#39025}
-
ulan authored
BUG=chromium:616434 LOG=NO Review-Url: https://codereview.chromium.org/2294783002 Cr-Commit-Position: refs/heads/master@{#39024}
-
addaleax authored
When FieldType::None() returns a cast Smi::FromInt(0), which translates as nullptr, the FieldType::IsNone() check becomes equivalent to `this == nullptr` which is not allowed by the standard and therefore optimized away as a false constant by GCC 6. This has lead to crashes when invoking methods on FieldType::None(). Using a different Smi constant for FieldType::None() makes the compiler always include a comparison against that value. The choice of these constants has no effect as they are effectively arbitrary. BUG=https://github.com/nodejs/node/issues/8310 Review-Url: https://codereview.chromium.org/2292953002 Cr-Commit-Position: refs/heads/master@{#39023}
-
ahaas authored
If the input of grow-memory was not representable as a SMI, then the input was not passed correctly to the runtime, which caused a crash. With this CL the input of grow-memory is checked before the runtime is called. R=titzer@chromium.org, gdeepti@chromium.org TEST=mjsunit/wasm/grow-memory.js:testGrowMemoryTrapsWithNonSmiInput() Review-Url: https://codereview.chromium.org/2288773002 Cr-Commit-Position: refs/heads/master@{#39022}
-
ahaas authored
Hi Brad, am I right that the two files that I added to .gitignore are generated by your fuzzer CL (https://codereview.chromium.org/2273303002/)? Cheers, Andreas R=bradnelson@chromium.org Review-Url: https://codereview.chromium.org/2289163002 Cr-Commit-Position: refs/heads/master@{#39021}
-
mvstanton authored
BUG= Review-Url: https://codereview.chromium.org/2291103002 Cr-Commit-Position: refs/heads/master@{#39020}
-
epertoso authored
[turbofan] Treat the INT32 state of a truncating binary op IC as number or oddball on 32-bit machines. This was causing a few unexpected deopt loops. BUG=v8:5320 Review-Url: https://codereview.chromium.org/2292873002 Cr-Commit-Position: refs/heads/master@{#39019}
-
jochen authored
Original issue's description: > Release streamed script resources after it was compiled > > Otherwise, we'd hold on to the resources until the embedder frees them > which might take a long time > > R=marja@chromium.org,verwaest@chromium.org > BUG= > > Committed: https://crrev.com/877dac34465c018bb534b7781fbe242ae4e33c32 > Cr-Commit-Position: refs/heads/master@{#38999} TBR=marja@chromium.org,verwaest@chromium.org BUG=chromium:642347 Review-Url: https://codereview.chromium.org/2296733002 Cr-Commit-Position: refs/heads/master@{#39018}
-
jbroman authored
BUG=chromium:148757 Review-Url: https://codereview.chromium.org/2290753002 Cr-Commit-Position: refs/heads/master@{#39017}
-
ulan authored
Now incremental marking tracing outputs isolate and timestamp: [41894:0x21efec0] 17253 ms: [IncrementalMarking] Start (old space step) This patch also adds walltime duration of incremental marking to GC trace output. BUG= Review-Url: https://codereview.chromium.org/2293883002 Cr-Commit-Position: refs/heads/master@{#39016}
-
jgruber authored
This commit introduces several new types: * JSStackFrame and WasmStackFrame are wrapper classes around a single frame in a FrameArray. * They both inherit from StackFrameBase, which uses virtual dispatch to call the correct implementation. * FrameArrayIterator contains a static instance of JSStackFrame and WasmStackFrame and returns a pointer to the corresponding type for each frame. * The JS callsite object now contains the frame array and frame index as internal fields. Internal stack formatting now relies completely on FrameArrayIterator and the {JS,Wasm}StackFrame types. JS callsite instances are allocated only for custom user formatting through Error.prepareStackTrace. BUG= Review-Url: https://codereview.chromium.org/2275233002 Cr-Commit-Position: refs/heads/master@{#39015}
-
ahaas authored
With this CL we use isolate->native_context() to provide a context for the CEntryStub of the runtime call. The native_context() is sufficient here because Runtime::kWasmThrowTypeError does not use the context. R=titzer@chromium.org TEST=mjsunit/wasm/ffi-error.js BUG=chromium:639492 Review-Url: https://codereview.chromium.org/2291043002 Cr-Commit-Position: refs/heads/master@{#39014}
-
mlippautz authored
R=ulan@chromium.org BUG= Review-Url: https://codereview.chromium.org/2292073002 Cr-Commit-Position: refs/heads/master@{#39013}
-
machenbach authored
Revert of Release streamed script resources after it was compiled (patchset #1 id:1 of https://codereview.chromium.org/2297523002/ ) Reason for revert: Seems to break webkit unit tests: https://build.chromium.org/p/client.v8.fyi/builders/V8-Blink%20Linux%2064/builds/9360 https://build.chromium.org/p/client.v8.fyi/builders/V8-Blink%20Linux%2064%20%28dbg%29/builds/5503 Original issue's description: > Release streamed script resources after it was compiled > > Otherwise, we'd hold on to the resources until the embedder frees them > which might take a long time > > R=marja@chromium.org,verwaest@chromium.org > BUG= > > Committed: https://crrev.com/877dac34465c018bb534b7781fbe242ae4e33c32 > Cr-Commit-Position: refs/heads/master@{#38999} TBR=marja@chromium.org,verwaest@chromium.org,jochen@chromium.org # Skipping CQ checks because original CL landed less than 1 days ago. NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true BUG= Review-Url: https://codereview.chromium.org/2290173003 Cr-Commit-Position: refs/heads/master@{#39012}
-
jochen authored
R=machenbach@chromium.org BUG= Review-Url: https://codereview.chromium.org/2295703002 Cr-Commit-Position: refs/heads/master@{#39011}
-
v8-autoroll authored
Rolling v8/build to 52f474cdb9e67007b938fd4a47220cb3c012e5e8 Rolling v8/third_party/WebKit/Source/platform/inspector_protocol to 84d90b2cc3f01a39bf73a8119a5cec0337d00c9f Rolling v8/tools/clang to 3e1948978834c16073c1b076410df1a80adda1f5 Rolling v8/tools/mb to ac239cc82ef08858d6f2b75216dd13afcdbc6ac3 TBR=machenbach@chromium.org,vogelheim@chromium.org,hablich@chromium.org Committed: https://crrev.com/3b8a2e5129fec64674bb0191cba5aa4592d08d5f Review-Url: https://codereview.chromium.org/2289063002 Cr-Original-Commit-Position: refs/heads/master@{#38995} Cr-Commit-Position: refs/heads/master@{#39010}
-
machenbach authored
Port https://codereview.chromium.org/2267753002/ BUG=474921 TBR=jochen@chromium.org, kjellander@chromium.org, vogelheim@chromium.org Review-Url: https://codereview.chromium.org/2290213002 Cr-Commit-Position: refs/heads/master@{#39009}
-
jochen authored
R=marja@chromium.org,verwaest@chromium.org BUG= Review-Url: https://codereview.chromium.org/2293803002 Cr-Commit-Position: refs/heads/master@{#39008}
-
Miran.Karic authored
For arch variants loongson and r1 neg instruction does not change the sign for NaN-like operands, the same as r2 neg. This fix adjusts macro assembler Neg_s and Neg_d arch variant logic so the correct code would be generated for loongson and r1. BUG= Review-Url: https://codereview.chromium.org/2287333002 Cr-Commit-Position: refs/heads/master@{#39007}
-
epertoso authored
BUG=v8:5273 Review-Url: https://codereview.chromium.org/2286273002 Cr-Commit-Position: refs/heads/master@{#39006}
-
bmeurer authored
Put the types for the Date builtins into the TypeCache, and add support for Date.prototype.getDay and Date.prototype.getMinutes. R=epertoso@chromium.org BUG=v8:5267 Review-Url: https://codereview.chromium.org/2296593002 Cr-Commit-Position: refs/heads/master@{#39005}
-
jacob.bramley authored
This replaces the target-selection options (such as "--enable-vfp3") with a simpler, absolute "--arm-arch" option. This eliminates inferences and avoids surprising behaviour in impossible situations (such as "--enable-vfp3 --no-enable-armv7"). The available options are: --arm-arch=armv6 ARMv6 + VFPv2 --arm-arch=armv7 ARMv7 + VFPv3-D32 + NEON --arm-arch=armv7+sudiv ARMv7 + VFPv4-D32 + NEON + SUDIV --arm-arch=armv8 ARMv8 (+ all of the above) For now, the default setting is "armv8", which results in behaviour very similar to the existing defaults. BUG=v8:5077 Review-Url: https://codereview.chromium.org/2223433002 Cr-Commit-Position: refs/heads/master@{#39004}
-
jochen authored
Instead of creating them on demand all over the place. I plan to link ScopeInfos together, and having one place where all ScopeInfos are created will make this easier. R=verwaest@chromium.org,adamk@chromium.org TBR=mstarzinger@chromium.org BUG=v8:5215 Review-Url: https://codereview.chromium.org/2281073002 Cr-Commit-Position: refs/heads/master@{#39003}
-
daniel.bevenius authored
The comment for the Proxy::New functions seems inaccurate and is currently identical to Map::New: 3090 /** 3091 * Creates a new empty Map. 3092 */ 3093 static Local<Map> New(Isolate* isolate); This commit updates the comment to describe that it creates a Proxy and not a Map. BUG= Review-Url: https://codereview.chromium.org/2176063002 Cr-Commit-Position: refs/heads/master@{#39002}
-
titzer authored
This CL is a prequisite for the stack machine changes, which will need to use temporaries in various places due to the stack height requirements on blocks. R=ahaas@chromium.org,bradnelson@chromium.org BUG= Review-Url: https://codereview.chromium.org/2280063002 Cr-Commit-Position: refs/heads/master@{#39001}
-
jbroman authored
It emits spurious -Wmaybe-uninitialized warnings. Initializing these variables shouldn't do any harm (with an optimizing compiler), so this seems the quickest way to mollify gcc. BUG=chromium:148757 Review-Url: https://codereview.chromium.org/2290653003 Cr-Commit-Position: refs/heads/master@{#39000}
-
jochen authored
Otherwise, we'd hold on to the resources until the embedder frees them which might take a long time R=marja@chromium.org,verwaest@chromium.org BUG= Review-Url: https://codereview.chromium.org/2297523002 Cr-Commit-Position: refs/heads/master@{#38999}
-
https://codereview.chromium.org/2289063002/machenbach authored
Reason for revert: Breaks tsan build generation: https://build.chromium.org/p/client.v8/builders/V8%20Linux64%20TSAN/builds/11441 Original issue's description: > Update V8 DEPS. > > Rolling v8/build to 52f474cdb9e67007b938fd4a47220cb3c012e5e8 > > Rolling v8/third_party/WebKit/Source/platform/inspector_protocol to 84d90b2cc3f01a39bf73a8119a5cec0337d00c9f > > Rolling v8/tools/clang to 3e1948978834c16073c1b076410df1a80adda1f5 > > Rolling v8/tools/mb to ac239cc82ef08858d6f2b75216dd13afcdbc6ac3 > > TBR=machenbach@chromium.org,vogelheim@chromium.org,hablich@chromium.org > > Committed: https://crrev.com/3b8a2e5129fec64674bb0191cba5aa4592d08d5f > Cr-Commit-Position: refs/heads/master@{#38995} TBR=hablich@chromium.org,vogelheim@chromium.org,v8-autoroll@chromium.org # Skipping CQ checks because original CL landed less than 1 days ago. NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true Review-Url: https://codereview.chromium.org/2290163002 Cr-Commit-Position: refs/heads/master@{#38998}
-
oth authored
TBR=rmcilroy@chromium.org BUG=NONE Review-Url: https://codereview.chromium.org/2290633004 Cr-Commit-Position: refs/heads/master@{#38997}
-
jgruber authored
This was exposed on win64 and manifested as a negative offset during stack frame collection, i.e. pc < Code::instruction_start() for a BUILTIN frame. This happened because StackFrame::LookupCode returns the wrong code object when call is the last instruction in a code object: * pc is actually the return address for all but the topmost frame. * pc points at the next instruction after the call. * This is beyond the current code object if call is the last instruction. * Lookup itself is naive in that it just returns the first code object for which (next_code_obj_addr > pc). It does not check that pc is actually within [instruction_start, instruction_end[. * In this specific case, the pc (== return address) actually pointed at the beginning of the header of the next code object. * We finally calculated offset as (code->instruction_start() - pc), but with the wrong code object. This should be followed up by a proper fix at some point. For instance, this could be setting pc to (return address - 1) for all but the topmost frame. BUG=v8:5311 Review-Url: https://codereview.chromium.org/2284673002 Cr-Commit-Position: refs/heads/master@{#38996}
-
v8-autoroll authored
Rolling v8/build to 52f474cdb9e67007b938fd4a47220cb3c012e5e8 Rolling v8/third_party/WebKit/Source/platform/inspector_protocol to 84d90b2cc3f01a39bf73a8119a5cec0337d00c9f Rolling v8/tools/clang to 3e1948978834c16073c1b076410df1a80adda1f5 Rolling v8/tools/mb to ac239cc82ef08858d6f2b75216dd13afcdbc6ac3 TBR=machenbach@chromium.org,vogelheim@chromium.org,hablich@chromium.org Review-Url: https://codereview.chromium.org/2289063002 Cr-Commit-Position: refs/heads/master@{#38995}
-
akos.palfi authored
Fixes the MIPS big-endian build after https://codereview.chromium.org/2276733002/ . BUG= Review-Url: https://codereview.chromium.org/2296473002 Cr-Commit-Position: refs/heads/master@{#38994}
-