- 27 Oct, 2015 23 commits
-
-
machenbach authored
BUG=chromium:535160 LOG=n Review URL: https://codereview.chromium.org/1424863002 Cr-Commit-Position: refs/heads/master@{#31608}
-
jkummerow authored
Full-codegen prepared for the bailout in the wrong place, causing side effects to be replayed when they shouldn't. Crankshaft and Turbofan are in agreement about where the deopt should jump to. TEST=mjsunit/for-in-opt R=jarin@chromium.org BUG=v8:4381 LOG=y Review URL: https://codereview.chromium.org/1413923005 Cr-Commit-Position: refs/heads/master@{#31607}
-
Michael Achenbach authored
Cr-Commit-Position: refs/heads/master@{#31606}
-
mbrandy authored
kExpectedPages should be ceil(kNumObjects / kNumObjectsPerPage) R=mlippautz@chromium.org, hpayer@chromium.org BUG= Review URL: https://codereview.chromium.org/1418143004 Cr-Commit-Position: refs/heads/master@{#31605}
-
rmcilroy authored
BUG=v8:4280 LOG=N Review URL: https://codereview.chromium.org/1413703007 Cr-Commit-Position: refs/heads/master@{#31604}
-
danno authored
Up until now, if one wanted to specify an explicit stack location or register as an operand for an instruction, it had to also be explicitly associated with a virtual register as a so-called FixedRegister or FixedStackSlot. For the implementation of tail calls, the plan is to use the gap resolver needs to shuffle stack locations from the caller to the tail-called callee. In order to do this, it must be possible to explicitly address operand locations on the stack that are not associated with virtual registers. This CL introduces ExplictOperands, which can specify a specific register or stack location that is not associated with virtual register. This will allow tail calls to specify the target locations for the necessary stack moves in the gap for the tail call without the core register allocation having to know about the target of the stack moves at all. In the process this CL: * creates a new Operand kind, ExplicitOperand, with which instructions can specify register and stack slots without an associated virtual register. * creates a LocationOperand class from which AllocatedOperand and ExplicitOperand are derived and provides a common interface to get Register, DoubleRegister and spill slot information. * removes RegisterOperand, DoubleRegisterOperand, StackSlotOperand and DoubleStackSlotOperand, they are subsumed by LocationOperand. * addresses a cleanup TODO in AllocatedOperand to reduce the redundancy of AllocatedOperand::Kind by using machine_type() to determine if an operand corresponds to a general purpose or double register. BUG=v8:4076 LOG=n Review URL: https://codereview.chromium.org/1389373002 Cr-Commit-Position: refs/heads/master@{#31603}
-
jarin authored
Review URL: https://codereview.chromium.org/1418423007 Cr-Commit-Position: refs/heads/master@{#31602}
-
Michael Achenbach authored
Cr-Commit-Position: refs/heads/master@{#31601}
-
ulan authored
BUG=chromium:490559 LOG=NO Review URL: https://codereview.chromium.org/1420363004 Cr-Commit-Position: refs/heads/master@{#31600}
-
mythria authored
Adds a scavenge GC pass that collects unmodified references instead of processing object groups. This mode can be controlled by setting FLAG_scavenge_reclaim_unmodified_objects. By default this is turned off. Also, modified a test case to suit the handle the new GC pass. BUG=v8:4421 LOG=N Review URL: https://codereview.chromium.org/1410593005 Cr-Commit-Position: refs/heads/master@{#31599}
-
mstarzinger authored
This introduces a JSConvertReceiver operator to model the implicit conversion of receiver values for sloppy callees. It is used by the JSInliner for now, but can also be used to model direction function calls that bypass call stubs. Also note that a hint is passed to said operator whenever the source structure constrains the receiver value type. This hint allows for optimizations in the lowering of the operator. The underlying specification in ES6, section 9.2.1.2 is the basis for this implementation. R=bmeurer@chromium.org TEST=mjsunit/compiler/receiver-conversion BUG=v8:4493, v8:4470 LOG=n Review URL: https://codereview.chromium.org/1412223015 Cr-Commit-Position: refs/heads/master@{#31598}
-
mvstanton authored
BUG= Review URL: https://codereview.chromium.org/1410223007 Cr-Commit-Position: refs/heads/master@{#31597}
-
bmeurer authored
Change CompareNilIC to return true/false instead of 1/0, and use the CompareNilICStub in TurboFan for abstract equality with null/undefined. This way we don't always run into the %Equals runtime fallback when comparing objects with null/undefined. R=jarin@chromium.org Review URL: https://codereview.chromium.org/1417503008 Cr-Commit-Position: refs/heads/master@{#31596}
-
neis authored
R=jochen BUG= Review URL: https://codereview.chromium.org/1424793004 Cr-Commit-Position: refs/heads/master@{#31595}
-
bmeurer authored
Currently we still (mis)used some machine operators in typed lowering (namely Word32Or, Word32Xor and Word32And). But these operators are "polymorphic" in the signedness of their inputs and output, hence the representation selection (and thereby simplified lowering) was unable to figure out whether a bitwise operation that was seen would produce an unsigned or a signed result. If such nodes also have frame state uses, the only safe choice was float64, which was not only a lot less ideal, but also the main cause of the for-in related deoptimizer loops. Adding dedicated NumberBitwiseOr, NumberBitwiseAnd and NumberBitwiseXor simplified operators not only gives us precise (and correct) typing for the bitwise operations, but also allows us to actually verify the graph properly after typed lowering. Drive-by-fix: Remove the double-to-smi magic from the Deoptimizer, which is responsible for various deopt-loops in TurboFan, and is no longer needed with the addition of the NumberBitwise operators. R=jarin@chromium.org Review URL: https://codereview.chromium.org/1422213002 Cr-Commit-Position: refs/heads/master@{#31594}
-
yangguo authored
With ES6 21.2.5.8, step 13, we no longer have to keep up the illusion that matching and calling replace function is interleaved. This is observable through unspec'ed static properties such as RegExp.$1. Last match info not working yet. R=littledan@chromium.org Review URL: https://codereview.chromium.org/1418703003 Cr-Commit-Position: refs/heads/master@{#31593}
-
chunyang.dai authored
The test mjsunit/regress/regress-sqrt compares the result of Math.sqrt function when using full-compiler and turbofan/crankshaft compiler seperately. But according to glibc bug fixing(https://sourceware.org/bugzilla/show_bug.cgi?id=14032). The glibc implementation of std::sqrt() (It is invoked in the generated code when full-compiler is used.) will change since glibc 2.19. In order to keep consistence of Math.sqrt translation in turbofan compiler and the pass of mjsunit/regress/regress-sqrt. we translate the Math.sqrt func according to the same fix in glibc change. If the GLIBC version >=2.19, we will set the precision to Double. (the original is extended-double). This fix is to fix the same issue in https://codereview.chromium.org/606403002 for crankshaft. This fix may be ported for crankshaft too. BUG= Review URL: https://codereview.chromium.org/1425763002 Cr-Commit-Position: refs/heads/master@{#31592}
-
bmeurer authored
Abstract equality of boolean values reduces to reference equality. R=verwaest@chromium.org Review URL: https://codereview.chromium.org/1425773002 Cr-Commit-Position: refs/heads/master@{#31591}
-
littledan authored
Revert of Check that array length stays a safe integer in Array.prototype.push (patchset #7 id:120001 of https://codereview.chromium.org/1428483002/ ) Reason for revert: Caused for-in-opt test to fail Original issue's description: > Check that array length stays a safe integer in Array.prototype.push > > This patch adds a check in Array.prototype.push to assert that the new > length does not become greater than 2**53-1. Such a length would be > dangerous because integer arithmetic becomes imprecise after the > boundary. The check is also required by a test262 test. > > R=adamk > LOG=Y > BUG=v8:3087 > > Committed: https://crrev.com/e68adf4548dd101dc08fcbff14444152fb1b7fe7 > Cr-Commit-Position: refs/heads/master@{#31588} TBR=adamk@chromium.org NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true BUG=v8:3087 Review URL: https://codereview.chromium.org/1418093007 Cr-Commit-Position: refs/heads/master@{#31590}
-
bmeurer authored
Reduce code duplication somewhat restructure the code to make it easier to spot the code paths for the different property cell types. R=jarin@chromium.org BUG=v8:4470 LOG=n Review URL: https://codereview.chromium.org/1413383004 Cr-Commit-Position: refs/heads/master@{#31589}
-
littledan authored
This patch adds a check in Array.prototype.push to assert that the new length does not become greater than 2**53-1. Such a length would be dangerous because integer arithmetic becomes imprecise after the boundary. The check is also required by a test262 test. R=adamk LOG=Y BUG=v8:3087 Review URL: https://codereview.chromium.org/1428483002 Cr-Commit-Position: refs/heads/master@{#31588}
-
adamk authored
- inner_scope_uses_arguments_ was completely unused - The public accessor for contains_with() was not called - inside_with() had helper methods on Parser and PatternRewriter, but was only called in one place. Review URL: https://codereview.chromium.org/1409253007 Cr-Commit-Position: refs/heads/master@{#31587}
-
ahaas authored
R=titzer@chromium.org Review URL: https://codereview.chromium.org/1423923003 Cr-Commit-Position: refs/heads/master@{#31586}
-
- 26 Oct, 2015 17 commits
-
-
Michael Achenbach authored
Cr-Commit-Position: refs/heads/master@{#31585}
-
rmcilroy authored
Adds support for loading from and storing to outer context variables. Also adds support for declaring functions on contexts and locals. Finally, fixes a couple of issues with StaContextSlot where we weren't emitting the write barrier and therefore would crash in the GC. Also added code so that --print-bytecode will output the function name before the bytecodes, and replaces MachineType with StoreRepresentation in RawMachineAssembler::Store and updates tests. BUG=v8:4280 LOG=N Review URL: https://codereview.chromium.org/1425633002 Cr-Commit-Position: refs/heads/master@{#31584}
-
mbrandy authored
Fix additional cases where the AIX compiler reports that a variable may be used uninitialized. R=danno@chromium.org, michael_dawson@ca.ibm.com BUG= Review URL: https://codereview.chromium.org/1420273006 Cr-Commit-Position: refs/heads/master@{#31583}
-
paul.lind authored
The upper 32-bits of the FP compare register are undefined in the float32 case. The compare instruction returns all 1's or all 0's, so just use the LS bit. Remove unnecessary use of 'at' reg. Change mips32 for consistency, but it did not have the bug. TEST=mjsunit/asm/embenchen/box2d (r6) BUG= Review URL: https://codereview.chromium.org/1425603002 Cr-Commit-Position: refs/heads/master@{#31582}
-
mtrofin authored
https://codereview.chromium.org/1412123009/ )" This reverts commit 5308a999. BUG=chromium:546416 LOG=N Review URL: https://codereview.chromium.org/1424653004 Cr-Commit-Position: refs/heads/master@{#31581}
-
cbruni authored
LOG=N BUG=v8:4026 Review URL: https://codereview.chromium.org/1416873008 Cr-Commit-Position: refs/heads/master@{#31580}
-
mbrandy authored
R=hpayer@chromium.org, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com, dstence@us.ibm.com BUG=chromium:542823 LOG=n Review URL: https://codereview.chromium.org/1415143004 Cr-Commit-Position: refs/heads/master@{#31579}
-
jkummerow authored
along with follow-up fixes: - "introduce LookupIterator::Restart() and use it" - "always reset the LookupIterator before storing" - "API-style accessors can throw, check for that" Revert reason was fixed in Chromium: https://codereview.chromium.org/1415453003/ This reverts the following commits: 0188aead 984f8af8 dc9d2c16 a0f5d499 Review URL: https://codereview.chromium.org/1424503003 Cr-Commit-Position: refs/heads/master@{#31578}
-
bmeurer authored
Drive-by-fix: Move IC::GetRootConstructor to Map::GetConstructorFunction, so we can use that in the ICs, Crankshaft and Turbofan. R=jarin@chromium.org BUG=v8:4470 LOG=n Review URL: https://codereview.chromium.org/1416493007 Cr-Commit-Position: refs/heads/master@{#31577}
-
yangguo authored
R=bmeurer@chromium.org Committed: https://crrev.com/15f36b2b1e166a511966a9991fddea94f890a755 Cr-Commit-Position: refs/heads/master@{#31566} Review URL: https://codereview.chromium.org/1423833003 Cr-Commit-Position: refs/heads/master@{#31576}
-
rmcilroy authored
Adds support and tests for conditional (ternary) expressions. BUG=v8:4280 LOG=N Review URL: https://codereview.chromium.org/1417053004 Cr-Commit-Position: refs/heads/master@{#31575}
-
ofrobots authored
Revert of [heap] remove unneeded call to LowerInlineAllocationLimit (patchset #2 id:20001 of https://codereview.chromium.org/1390013002/ ) Reason for revert: Causes memory footprint regression: https://code.google.com/p/chromium/issues/detail?id=541135 The intent of the code here was to advance the inline allocation limit without counting the allocated memory towards a step. Calling LowerInlineAllocationLimit this way is a blunt way of doing it, but it works. At this point it is simplest to revert this CL. My follow-on CL (https://codereview.chromium.org/1404523002/) can address the 'bluntness' of calling LowerInlineAllocationLimit from here along with leaving a comment about the intent. revert_cq: 1 revert_reason_textarea: Causes memory footprint regression: https://code.google.com/p/chromium/issues/detail?id=541135 The intent of the code here was to advance the inline allocation limit without counting the allocated memory towards a step. Calling LowerInlineAllocationLimit this way is a blunt way of doing it, but it works. At this point it is simplest to revert this CL. My follow-on CL (https://codereview.chromium.org/1404523002/) can address the 'bluntness' of calling LowerInlineAllocationLimit from here along with leaving a comment about the intent. Original issue's description: > [heap] remove unneeded call to LowerInlineAllocationLimit > > Calling LowerInlineAllocationLimit from the bottom of Heap::Scavenge seems to be > a no-op. > > new_space_.LowerInlineAllocationLimit( > new_space_.inline_allocation_limit_step()); > > LowerInlineAllocatoinLimit does the following things: > > 1. Set the inline_allocation_limit_step_ to the passed in value. No-op. > 2. Calls UpdateInlineAllocationLimit(0). This is unnecessary here as it has > already been called when new_space_.ResetAllocationInfo was called above. > 3. Sets top_on_previous_step_. This again is unnecessary as it gets reached by > ResetAllocationInfo as well. > > BUG= > R=hpayer@chromium.org,ulan@chromium.org > > Committed: https://crrev.com/9f8e8b835a468b1622c5350a01a97bc32c5b2fb7 > Cr-Commit-Position: refs/heads/master@{#31156} TBR=hpayer@chromium.org,ulan@chromium.org NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true BUG=chromium:541135 LOG=n Review URL: https://codereview.chromium.org/1405043005 Cr-Commit-Position: refs/heads/master@{#31574}
-
neis authored
BUG= Review URL: https://codereview.chromium.org/1422973002 Cr-Commit-Position: refs/heads/master@{#31573}
-
mstarzinger authored
R=bmeurer@chromium.org TEST=mjsunit/tools/profviz BUG=v8:4493 LOG=n Review URL: https://codereview.chromium.org/1419333003 Cr-Commit-Position: refs/heads/master@{#31572}
-
machenbach authored
Revert of Assume that ReportFailedAccessCheck always schedules an exception. (patchset #1 id:1 of https://codereview.chromium.org/1420413002/ ) Reason for revert: [Sheriff] Crashes in layout tests: http://build.chromium.org/p/client.v8.fyi/builders/V8-Blink%20Linux%2064/builds/2539 # # Fatal error in , line 0 # unreachable code # Original issue's description: > Assume that ReportFailedAccessCheck always schedules an exception. > > R=verwaest@chromium.org > BUG= > > Committed: https://crrev.com/effe76ad25c23bfd8be447930bd5d5126b1c9096 > Cr-Commit-Position: refs/heads/master@{#31560} TBR=verwaest@chromium.org,neis@chromium.org NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true BUG= Review URL: https://codereview.chromium.org/1424703002 Cr-Commit-Position: refs/heads/master@{#31571}
-
yangguo authored
Revert of Canonicalize handles for optimized compilation. (patchset #1 id:1 of https://codereview.chromium.org/1423833003/ ) Reason for revert: GC stress failure on ia32 optdebug: /tmp/runfswAKT/out/Debug/d8 --test --random-seed=-1536184370 --turbo --always-opt --nohard-abort --nodead-code-elimination --nofold-constants --enable-slow-asserts --debug-code --verify-heap --stack-size=46 /tmp/runfswAKT/test/mjsunit/mjsunit.js /tmp/runfswAKT/test/mjsunit/regress/regress-1132.js --gc-interval=500 --stress-compaction --concurrent-recompilation-queue-length=64 --concurrent-recompilation-delay=500 --concurrent-recompilation Run #1 Exit code: -6 Result: FAIL Expected outcomes: PASS Duration: 00:06:279 Stderr: # # Fatal error in ../../src/hashmap.h, line 248 # Check failed: base::bits::IsPowerOfTwo32(capacity_). # ==== C stack trace =============================== Original issue's description: > Canonicalize handles for optimized compilation. > > R=bmeurer@chromium.org > > Committed: https://crrev.com/15f36b2b1e166a511966a9991fddea94f890a755 > Cr-Commit-Position: refs/heads/master@{#31566} TBR=jochen@chromium.org,bmeurer@chromium.org NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true Review URL: https://codereview.chromium.org/1417013007 Cr-Commit-Position: refs/heads/master@{#31570}
-
mstarzinger authored
R=mvstanton@chromium.org Review URL: https://codereview.chromium.org/1425643002 Cr-Commit-Position: refs/heads/master@{#31569}
-