- 25 Apr, 2016 9 commits
-
-
baptiste.afsa authored
R=jarin@chromium.org Review URL: https://codereview.chromium.org/1905883003 Cr-Commit-Position: refs/heads/master@{#35752}
-
baptiste.afsa authored
This patch make sure that the nop instructions used to mark floating-point arguments live range begin will not be moved by the scheduler. R=jarin@chromium.org Review URL: https://codereview.chromium.org/1896933004 Cr-Commit-Position: refs/heads/master@{#35751}
-
yangguo authored
R=mstarzinger@chromium.org, rossberg@chromium.org BUG=v8:4690 LOG=N Review URL: https://codereview.chromium.org/1906653004 Cr-Commit-Position: refs/heads/master@{#35750}
-
jarin authored
Review URL: https://codereview.chromium.org/1914943002 Cr-Commit-Position: refs/heads/master@{#35749}
-
bmeurer authored
The ObjectIs<Type> predicates compile down to diamonds (in the general case), and those should be connected properly to the control and effect chain in the linearization pass. R=jarin@chromium.org Review URL: https://codereview.chromium.org/1912743002 Cr-Commit-Position: refs/heads/master@{#35748}
-
jarin authored
Review URL: https://codereview.chromium.org/1921483002 Cr-Commit-Position: refs/heads/master@{#35747}
-
v8-autoroll authored
Rolling v8/tools/clang to db76f9f1d1ed7f4c4db1bf10f530506614375db3 TBR=machenbach@chromium.org,vogelheim@chromium.org,hablich@chromium.org Review URL: https://codereview.chromium.org/1912413002 Cr-Commit-Position: refs/heads/master@{#35746}
-
zhengxing.li authored
port 0231a7ef (r35743) original commit message: This allows us to get rid of the "push TruncateFloat64ToInt32 into Phi" trick that was used in the MachineOperatorReducer to combine the ChangeTaggedToFloat64 and TruncateFloat64ToInt32 operations. Instead of doing that later, we can just introduce the proper operator during the representation selection directly. Also separate the TruncateFloat64ToInt32 machine operator, which had two different meanings depending on a flag (either JavaScript truncation or C++ style round to zero). Now there's a TruncateFloat64ToWord32 which represents the JavaScript truncation (implemented via TruncateDoubleToI macro + code stub) and the RoundFloat64ToInt32, which implements the C++ round towards zero operation (in the same style as the other WebAssembly driven Round* machine operators). BUG= Review URL: https://codereview.chromium.org/1912403002 Cr-Commit-Position: refs/heads/master@{#35745}
-
zhengxing.li authored
port 5c8609de (r35724) original commit message: This ensures the InterpreterEntryTrampoline heals code entry fields inside closures when being called without a valid bytecode array. This is preparatory work to allow removal of bytecode when switching some functions to other types of code. BUG= Review URL: https://codereview.chromium.org/1920713002 Cr-Commit-Position: refs/heads/master@{#35744}
-
- 24 Apr, 2016 1 commit
-
-
bmeurer authored
This allows us to get rid of the "push TruncateFloat64ToInt32 into Phi" trick that was used in the MachineOperatorReducer to combine the ChangeTaggedToFloat64 and TruncateFloat64ToInt32 operations. Instead of doing that later, we can just introduce the proper operator during the representation selection directly. Also separate the TruncateFloat64ToInt32 machine operator, which had two different meanings depending on a flag (either JavaScript truncation or C++ style round to zero). Now there's a TruncateFloat64ToWord32 which represents the JavaScript truncation (implemented via TruncateDoubleToI macro + code stub) and the RoundFloat64ToInt32, which implements the C++ round towards zero operation (in the same style as the other WebAssembly driven Round* machine operators). R=jarin@chromium.org Review URL: https://codereview.chromium.org/1919513002 Cr-Commit-Position: refs/heads/master@{#35743}
-
- 23 Apr, 2016 1 commit
-
-
mtrofin authored
If a deferred block has multiple predecessors, they have to be all deferred. Otherwise, we can run into a situation where if a range that spills only in deferred blocks inserts its spill in the block, and other ranges need moves inserted by ResolveControlFlow in the predecessors, the register of the range spilled in the deferred block may be clobbered. To avoid that, when a deferred block has multiple predecessors, and some are not deferred, we add a non-deferred block to collect all such edges. This CL addresses the validator assertion failure the referenced issue, as well as the greedy allocator failure - which was caused by the situation described above. BUG=v8:4940 LOG=n Review URL: https://codereview.chromium.org/1912093005 Cr-Commit-Position: refs/heads/master@{#35742}
-
- 22 Apr, 2016 29 commits
-
-
mbrandy authored
Need to use the kHashFieldSlot rather than kHashFieldOffset for pointer-sized memory accesses. (Fix for "[builtins] Migrate String.prototype.charCodeAt and String.prototype.charAt to TurboFan.") R=bmeurer@chromium.org, epertoso@chromium.org BUG= Review URL: https://codereview.chromium.org/1907393002 Cr-Commit-Position: refs/heads/master@{#35741}
-
Adam Klein authored
TBR=machenbach@chromium.org Review URL: https://codereview.chromium.org/1907423002 . Cr-Commit-Position: refs/heads/master@{#35740}
-
bjaideep authored
Port 5c8609de Original commit message: This ensures the InterpreterEntryTrampoline heals code entry fields inside closures when being called without a valid bytecode array. This is preparatory work to allow removal of bytecode when switching some functions to other types of code. R=mstarzinger@chromium.org, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com, mbrandy@us.ibm.com BUG=v8:4280 LOG=N Review URL: https://codereview.chromium.org/1913173002 Cr-Commit-Position: refs/heads/master@{#35739}
-
jarin authored
Review URL: https://codereview.chromium.org/1914493002 Cr-Commit-Position: refs/heads/master@{#35738}
-
mbrandy authored
The offset from fp to the register file is based on the frame size -- which is one slot larger when embedded constant pools are enabled. TEST=unittests/DecodeBytecodeAndOperands TBR=rmcilroy@chromium.org, bmeurer@chromium.org, oth@chromium.org, mstarzinger@chromium.org BUG= Review URL: https://codereview.chromium.org/1906963002 Cr-Commit-Position: refs/heads/master@{#35735} Review URL: https://codereview.chromium.org/1909283003 Cr-Commit-Position: refs/heads/master@{#35737}
-
mbrandy authored
Revert of Fix interpreter unittest for embedded constant pools. (patchset #2 id:20001 of https://codereview.chromium.org/1906963002/ ) Reason for revert: Need to fix the #undef logic. Original issue's description: > Fix interpreter unittest for embedded constant pools. > > The offset from fp to the register file is based on the frame size > -- which is one slot larger when embedded constant pools are enabled. > > TEST=unittests/DecodeBytecodeAndOperands > R=rmcilroy@chromium.org, bmeurer@chromium.org, oth@chromium.org, mstarzinger@chromium.org > BUG= TBR=bmeurer@chromium.org,mstarzinger@chromium.org,oth@chromium.org,rmcilroy@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/1909323003 Cr-Commit-Position: refs/heads/master@{#35736}
-
mbrandy authored
The offset from fp to the register file is based on the frame size -- which is one slot larger when embedded constant pools are enabled. TEST=unittests/DecodeBytecodeAndOperands R=rmcilroy@chromium.org, bmeurer@chromium.org, oth@chromium.org, mstarzinger@chromium.org BUG= Review URL: https://codereview.chromium.org/1906963002 Cr-Commit-Position: refs/heads/master@{#35735}
-
rossberg authored
TBR=hablich@chromium.org BUG= Review URL: https://codereview.chromium.org/1915453002 Cr-Commit-Position: refs/heads/master@{#35734}
-
mbrandy authored
TEST=cctest/test-run-load-store/* R=joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com, bjaideep@ca.ibm.com BUG= Review URL: https://codereview.chromium.org/1910123002 Cr-Commit-Position: refs/heads/master@{#35733}
-
mstarzinger authored
This also removes the destructor of the class in question, which removed any added decorator from the graph. However the adding of the decorator happens explicitly, so symmetry suggests that removal should also happen explicitly instead of implicitly in the destructor. R=bmeurer@chromium.org Review URL: https://codereview.chromium.org/1914473002 Cr-Commit-Position: refs/heads/master@{#35732}
-
epertoso authored
Removes some control edges added from the RawMachineAssembler to the end of the graph. Adds a parameter that tells the Verifier to ignore effect and control inputs. Review URL: https://codereview.chromium.org/1912853003 Cr-Commit-Position: refs/heads/master@{#35731}
-
mike authored
Refactor the Scope object to automatically enable strict mode when initialized as a "module" scope, relieving the caller of this responsibility. BUG=v8:4941 LOG=N R=adamk@chromium.org Review URL: https://codereview.chromium.org/1906923002 Cr-Commit-Position: refs/heads/master@{#35730}
-
yangguo authored
R=mstarzinger@chromium.org BUG=v8:4690 LOG=N Review URL: https://codereview.chromium.org/1903223003 Cr-Commit-Position: refs/heads/master@{#35729}
-
jarin authored
The approximate mode enables taking an approximate stack trace from GC, where the top frames might be missing if inlined. Note that in that case, the frame summary will refer to optimized code, so it will not be possible to take source position. (The user of the summary will have to handle the case frame_summary.abstract_code()->kind() == AbstractCode::OPTIMIZED_CODE specially.) Review URL: https://codereview.chromium.org/1907443002 Cr-Commit-Position: refs/heads/master@{#35728}
-
bmeurer authored
There's no point in running the SimplifiedOperatorReducer also during the late optimization pass, as it will not do any useful work at that point. R=jarin@chromium.org Review URL: https://codereview.chromium.org/1909363002 Cr-Commit-Position: refs/heads/master@{#35727}
-
rossberg authored
This does not affect use counters. R=nikolaos@chromium.org BUG= Review URL: https://codereview.chromium.org/1911963003 Cr-Commit-Position: refs/heads/master@{#35726}
-
jochen authored
Revert of [GN] Define USE_EABI_HARDFLOAT=1 when arm_float_abi=="hard". (patchset #1 id:1 of https://codereview.chromium.org/1839763003/ ) Reason for revert: Appears to break Android crbug.com/604422 Original issue's description: > [GN] Define USE_EABI_HARDFLOAT=1 when arm_float_abi=="hard". > > Add this define to the config used for mksnapshot. This fixes a bug > where certain applications would fail at runtime on Chromecast. > > BUG=592660 > LOG=Y > Bug: internal b/27495984 > > Test: Formerly broken Cast apps load and run as expected. > > Committed: https://crrev.com/86357d5235ceba61c151f0b6e509bcb365860454 > Cr-Commit-Position: refs/heads/master@{#35183} TBR=dpranke@chromium.org,alokp@chromium.org,titzer@chromium.org,slan@chromium.org # Not skipping CQ checks because original CL landed more than 1 days ago. BUG=592660,604422 LOG=n Review URL: https://codereview.chromium.org/1906373002 Cr-Commit-Position: refs/heads/master@{#35725}
-
mstarzinger authored
This ensures the InterpreterEntryTrampoline heals code entry fields inside closures when being called without a valid bytecode array. This is preparatory work to allow removal of bytecode when switching some functions to other types of code. R=rmcilroy@chromium.org BUG=v8:4280 LOG=n Review URL: https://codereview.chromium.org/1904093002 Cr-Commit-Position: refs/heads/master@{#35724}
-
bmeurer authored
Get rid of further typing checks from ChangeLowering and put them into the representation selection pass instead (encoding the information in the operator instead). Drive-by-change: Rename ChangeSmiToInt32 to ChangeTaggedSignedToInt32 for consistency about naming Tagged, TaggedSigned and TaggedPointer. R=jarin@chromium.org Review URL: https://codereview.chromium.org/1909343002 Cr-Commit-Position: refs/heads/master@{#35723}
-
lpy authored
Currently we are using UnsafeCurrent in async signal handler to acquire the isolate of VM thread, but we want to get rid of that since it prevents V8 from being thread agnostic. This patch replaces UnsafeCurrent with a static map, where we store a map of samplers for threads, and makes it accessible by signal handler. BUG=v8:4889 LOG=n Review URL: https://codereview.chromium.org/1900473002 Cr-Commit-Position: refs/heads/master@{#35722}
-
yangguo authored
Some scopes are introduced by the parser for desugaring and do not have any positions associated. The debugger should not make them visible. Also add some missing source positions. R=kozyatinskiy@chromium.org, rossberg@chromium.org BUG=chromium:604458 LOG=Y Review URL: https://codereview.chromium.org/1901413002 Cr-Commit-Position: refs/heads/master@{#35721}
-
rmcilroy authored
Adds IncStub and DecStub TurboFan code stubs and hooks them up to the interpreter's Inc and Dec bytecodes (which are used for count operations, e.g. i++). BUG=v8:4280 LOG=N Review URL: https://codereview.chromium.org/1901083002 Cr-Commit-Position: refs/heads/master@{#35720}
-
rmcilroy authored
Fixes a mistake made in r35618 for register OperandSize calculations. BUG=605470 LOG=N Review URL: https://codereview.chromium.org/1908033002 Cr-Commit-Position: refs/heads/master@{#35719}
-
machenbach authored
BUG=chromium:605516 LOG=n Review URL: https://codereview.chromium.org/1913013003 Cr-Commit-Position: refs/heads/master@{#35718}
-
ulan authored
BUG=chromium:605349 LOG=NO Review URL: https://codereview.chromium.org/1912923003 Cr-Commit-Position: refs/heads/master@{#35717}
-
neis authored
The new bytecodes replace two runtime functions. They are still unsupported by the bytecode graphbuilder, though. BUG=v8:4907 LOG=n Review URL: https://codereview.chromium.org/1904933002 Cr-Commit-Position: refs/heads/master@{#35716}
-
jkummerow authored
This is a follow-up to 58429beb "Fix KeyedStore stub selection for STRING_WRAPPER_ELEMENTS". BUG=chromium:602184 LOG=n Review URL: https://codereview.chromium.org/1912443004 Cr-Commit-Position: refs/heads/master@{#35715}
-
adamk authored
The feature was deprecated in M49 and flagged off in M50. This patch removes it entirely from the codebase. Review URL: https://codereview.chromium.org/1909433003 Cr-Commit-Position: refs/heads/master@{#35714}
-
bmeurer authored
If we have to convert a float64 value to tagged representation and we already know that the value is either in Signed31/Signed32 or Unsigned32 range, then we can just convert the float64 to word32 and use the fast word32 to tagged conversion. Doing this in ChangeLowering (or the effect linearization pass) would be unsound, as the types on the nodes are no longer usable. This removes all Type uses from effect linearization. There's still some work to be done for ChangeLowering tho. R=jarin@chromium.org Review URL: https://codereview.chromium.org/1908093002 Cr-Commit-Position: refs/heads/master@{#35713}
-