- 16 Dec, 2015 25 commits
-
-
yangguo authored
The problem is this: when stepping over a recursive function call, the recursive function is flooded with one-shot break points so that we break after the call, but since the callee is the same function, the callee is also flooded, resulting a break in the callee. That however would have been a "step in" instead of "step over". The original solution was to recognize this by comparing FP. If we end up in Debug::Break, we still have to check the current FP against the remembered FP to see whether we are on the same stack height. If we are deeper, then it's not a "step over", and we do not trigger a debug break event. In that case, we queue up the step-over, and temporarily step out until we hit the desired stack height. Note that in order to step out, we flood the caller, which in our example is the same function as the callee. So we break at every flooded break location, and comparing with FP to make sure we stepped out prevents us from triggering debug break events. The new solution simply ignores breaks when the FP compare fails. We simply carry on until we hit a break where the FP compare succeeds. There is no need to do a step out. The number of calls to Debug::Break that do not trigger a debug break event due to failing FP compare is the same. But the code is a lot easier to read. R=jkummerow@chromium.org Review URL: https://codereview.chromium.org/1527253002 Cr-Commit-Position: refs/heads/master@{#32897}
-
jochen authored
While not really fitting our directory layout, the DEPS entry needs to be at exactly the same position as it is in chromium, otherwise either standalone or chromium build won't work :-/ BUG=none R=machenbach@chromium.org LOG=y Review URL: https://codereview.chromium.org/1526843004 Cr-Commit-Position: refs/heads/master@{#32896}
-
aseemgarg authored
TEST=asm-wasm.js R=titzer@chromium.org,bradnelson@google.com BUG= Review URL: https://codereview.chromium.org/1523843003 Cr-Commit-Position: refs/heads/master@{#32895}
-
ahaas authored
The new implementation also changes the sign bit if the input is NaN. (https://github.com/WebAssembly/v8-native-prototype/issues/99) R=bradnelson@chromium.org Review URL: https://codereview.chromium.org/1532513002 Cr-Commit-Position: refs/heads/master@{#32894}
-
ahaas authored
The code generation for pushing call parameters on the stack does not distinguish between float32 and float64 parameters because both are stored in the same registers. Therefore float32 parameters require two words on the stack. The wasm linkage, however, only considered one word on the stack for float32 parameters, which caused the problem that float32 parameters were not located correctly on the stack. I fixed the problem by considering two words for float32 parameters on the stack. R=bradnelson@chromium.org Review URL: https://codereview.chromium.org/1529773003 Cr-Commit-Position: refs/heads/master@{#32893}
-
jkummerow authored
BUG=v8:1543,chromium:570120 LOG=n Review URL: https://codereview.chromium.org/1530873002 Cr-Commit-Position: refs/heads/master@{#32892}
-
cbruni authored
LOG=n BUG=v8:1543 Review URL: https://codereview.chromium.org/1531683002 Cr-Commit-Position: refs/heads/master@{#32891}
-
bmeurer authored
Following up on https://crrev.com/1517243002, we use the %_GetSuperConstructor consistently for all super calls now (inlining the intrinsic code in fullcodegen). R=mstarzinger@chromium.org BUG=v8:3330 LOG=n Review URL: https://codereview.chromium.org/1529113002 Cr-Commit-Position: refs/heads/master@{#32890}
-
yangguo authored
R=hablich@chromium.org BUG=v8:4545 LOG=Y Review URL: https://codereview.chromium.org/1524233003 Cr-Commit-Position: refs/heads/master@{#32889}
-
caitpotter88 authored
BUG=v8:4613 LOG=N R=adamk@chromium.org Review URL: https://codereview.chromium.org/1522693002 Cr-Commit-Position: refs/heads/master@{#32888}
-
Miran.Karic authored
Fix invalid usage of layout_descriptor() function on 32-bit arch's, which doesn't perform necessary checks. Test failure is observed only on mips32 big-endian, and on mips32 little-endian as an alignment issue, but the problem appears to be generic for all 32-bit arch's. TEST=test/mjsunit/es6/classes-subclass-builtins.js BUG= Review URL: https://codereview.chromium.org/1522203004 Cr-Commit-Position: refs/heads/master@{#32887}
-
bmeurer authored
R=hablich@chromium.org Review URL: https://codereview.chromium.org/1531653002 Cr-Commit-Position: refs/heads/master@{#32886}
-
yangguo authored
And tons of changes to debugger tests. R=bmeurer@chromium.org BUG=chromium:569835 LOG=N Review URL: https://codereview.chromium.org/1525173003 Cr-Commit-Position: refs/heads/master@{#32885}
-
yangguo authored
R=jarin@chromium.org Review URL: https://codereview.chromium.org/1529823002 Cr-Commit-Position: refs/heads/master@{#32884}
-
bmeurer authored
The TypeOfStub didn't test the undetectable bit properly if the instance was also callable, and therefore returned "object" for document.all (which is both undetectable and callable). CQ_INCLUDE_TRYBOTS=tryserver.chromium.linux:linux_chromium_rel_ng;tryserver.blink:linux_blink_rel R=yangguo@chromium.org BUG=chromium:567998 LOG=n Committed: https://crrev.com/02cc310370df7e51ac4f705038820066fdfd0cdc Cr-Commit-Position: refs/heads/master@{#32852} Review URL: https://codereview.chromium.org/1527863003 Cr-Commit-Position: refs/heads/master@{#32883}
-
bmeurer authored
The %HeapObjectGetMap and %MapGetInstanceType intrinsics are obsolete because they are unsafe, so we can drop the code. R=yangguo@chromium.org Review URL: https://codereview.chromium.org/1532493002 Cr-Commit-Position: refs/heads/master@{#32882}
-
bmeurer authored
The JSCreateClosure operator always produces a function, so the type should reflect that. R=yangguo@chromium.org Review URL: https://codereview.chromium.org/1532503002 Cr-Commit-Position: refs/heads/master@{#32881}
-
bmeurer authored
If JSCreate (which corresponds to %NewObject) would ever trigger a lazy deopt, we would deopt after the constructor call, skipping all the initialization and what else in the constructor function, which is wrong. Instead we can use the eager bailout point right before the constructor function, because allocation is not observable and so we can safely repeat the %NewObject in case of lazy bailout. R=yangguo@chromium.org BUG=v8:4544 LOG=n Review URL: https://codereview.chromium.org/1530583004 Cr-Commit-Position: refs/heads/master@{#32880}
-
yangguo authored
TBR=adamk@chromium.org R=erik.corry@gmail.com BUG=v8:4616 LOG=N Review URL: https://codereview.chromium.org/1522353002 Cr-Commit-Position: refs/heads/master@{#32879}
-
bmeurer authored
Flatten ConsString objects in JSGraph, to make sure we consistently flatten all cons strings no matter which pass creates them. R=yangguo@chromium.org Review URL: https://codereview.chromium.org/1529053003 Cr-Commit-Position: refs/heads/master@{#32878}
-
yangguo authored
credits to gcov. R=cbruni@chromium.org Review URL: https://codereview.chromium.org/1522273003 Cr-Commit-Position: refs/heads/master@{#32877}
-
bmeurer authored
With the handle canonicalization we can now easily cache heap constant nodes based on the location of the HeapObject handle location. R=yangguo@chromium.org Review URL: https://codereview.chromium.org/1523323005 Cr-Commit-Position: refs/heads/master@{#32876}
-
mtrofin authored
...except for 2 places (map::insert and map::find returns) [turbofan] move down parallel moves BUG= Review URL: https://codereview.chromium.org/1531453003 Cr-Commit-Position: refs/heads/master@{#32875}
-
mtrofin authored
The regression the bug tracks (see the bug link) appears to be due to identical gap moves in the predecessors of a block not being moved to the common successor. This CR fixes one reason that is happening. BUG=chromium:549262 LOG=n Review URL: https://codereview.chromium.org/1523393003 Cr-Commit-Position: refs/heads/master@{#32874}
-
v8-autoroll authored
Rolling v8/third_party/icu to 8d342a405be5ae8aacb1e16f0bc31c3a4fbf26a2 Rolling v8/tools/clang to 6261565695263bd878edd055e81ecc5e989711d6 TBR=machenbach@chromium.org,vogelheim@chromium.org,hablich@chromium.org Review URL: https://codereview.chromium.org/1529973004 Cr-Commit-Position: refs/heads/master@{#32873}
-
- 15 Dec, 2015 15 commits
-
-
jkummerow authored
The proxy may be on its own target's or handler's prototype chain, leading to infinite recursion either when looking up the trap, or when calling through to the target. We can't eagerly prevent this from happening (e.g. at "foo.__proto__ = bar" calling time) because the presence of traps can change at any time. BUG=v8:1543,chromium:569882 LOG=n Review URL: https://codereview.chromium.org/1526953002 Cr-Commit-Position: refs/heads/master@{#32872}
-
ishell authored
BUG=chromium:514080,chromium:527994,v8:4325 LOG=N Review URL: https://codereview.chromium.org/1522413002 Cr-Commit-Position: refs/heads/master@{#32871}
-
mstarzinger authored
TBR=rmcilroy@chromium.org Review URL: https://codereview.chromium.org/1526983002 Cr-Commit-Position: refs/heads/master@{#32870}
-
baptiste.afsa authored
Original CL: https://codereview.chromium.org/1375253002/ Implement machine instruction scheduling after instruction selection. R=jarin@chromium.org Review URL: https://codereview.chromium.org/1526913003 Cr-Commit-Position: refs/heads/master@{#32869}
-
yangguo authored
credits to gcov. Review URL: https://codereview.chromium.org/1528843002 Cr-Commit-Position: refs/heads/master@{#32868}
-
mstarzinger authored
This fixes a path in the compilation pipeline that side-stepped the interpreter when a function literal was eagerly compiled. This caused the interpreter to miss some test coverage. R=rmcilroy@chromium.org Review URL: https://codereview.chromium.org/1528853002 Cr-Commit-Position: refs/heads/master@{#32867}
-
zhengxing.li authored
X87: [TurboFan] Change the implementation of Float32's NaN comparision's return value in kX87Float32Min and kX87Float32Max. The CL 32796(https://codereview.chromium.org/1512023002) adds many Float32 comparision test data which including the NaN comparision. As there's no Specification for the return value of NaN comparision, Current x87 will check the Float comparision instruction's first operand, if it's NaN, return the second operand. Otherwise, return itself. But this conflicts with the Gcc compiler's implementation and cause the RunFloat32MinP and RunFloat32MaxP tests failed. For (a < b) comparision, The Gcc compiler will treat the NaN comparision's result same as a GT b and return b. The minss sse instruction in IA32 has the similar behavior. So this CL will make the implementation of NaN comparision's return value in kX87Float32Min and kX87Float32Max same as Gcc and IA32. BUG= Review URL: https://codereview.chromium.org/1522333002 Cr-Commit-Position: refs/heads/master@{#32866}
-
yangguo authored
The third argument optionally specifies the frame from which to step. This feature is not used and not well tested. R=jkummerow@chromium.org BUG=chromium:569835 LOG=N Review URL: https://codereview.chromium.org/1525993002 Cr-Commit-Position: refs/heads/master@{#32865}
-
mstarzinger authored
This fixes runtime calls emitted by the RawMachineAssembler to use the correct CEntryStub depending on the return count of runtime functions. Note that this only affects WIN64 and PPC, where the ABI is different. R=mythria@chromium.org Review URL: https://codereview.chromium.org/1528643004 Cr-Commit-Position: refs/heads/master@{#32864}
-
yangguo authored
Revert of [debugger] re-enable step in frame test. (patchset #1 id:1 of https://codereview.chromium.org/1518403004/ ) Reason for revert: https://build.chromium.org/p/client.v8/builders/V8%20Linux%20-%20arm64%20-%20sim%20-%20gc%20stress/builds/4780/steps/Mjsunit/logs/debug-step-4-in-frame Original issue's description: > [debugger] re-enable step in frame test. > > Issue has long been fixed. > > R=jkummerow@chromium.org > BUG=v8:2921 > LOG=N > > Committed: https://crrev.com/f27105b17a23a64faeae33b939555840e388136e > Cr-Commit-Position: refs/heads/master@{#32862} TBR=jkummerow@chromium.org NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true BUG=v8:2921 Review URL: https://codereview.chromium.org/1522333003 Cr-Commit-Position: refs/heads/master@{#32863}
-
yangguo authored
Issue has long been fixed. R=jkummerow@chromium.org BUG=v8:2921 LOG=N Review URL: https://codereview.chromium.org/1518403004 Cr-Commit-Position: refs/heads/master@{#32862}
-
develar authored
R=yangguo@chromium.org Review URL: https://codereview.chromium.org/1477233002 Cr-Commit-Position: refs/heads/master@{#32861}
-
yangguo authored
Revert of [WIP][turbofan] Instruction scheduler for Turbofan. (patchset #7 id:120001 of https://codereview.chromium.org/1375253002/ ) Reason for revert: Does not compile https://build.chromium.org/p/client.v8/builders/V8%20Arm%20-%20debug%20builder/builds/6870/steps/compile/logs/stdio Original issue's description: > [turbofan] Instruction scheduler for Turbofan. > > Implement machine instruction scheduling after instruction selection. > > Currently only works for arm64. > > R=danno@chromium.org, bmeurer@chromium.org, titzer@chromium.org > > Committed: https://crrev.com/e11bba3acd5188f0e12686b6fcf3e0ab22989216 > Cr-Commit-Position: refs/heads/master@{#32858} TBR=jarin@chromium.org,bmeurer@chromium.org,baptiste.afsa@arm.com NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true Review URL: https://codereview.chromium.org/1526913002 Cr-Commit-Position: refs/heads/master@{#32860}
-
yangguo authored
credits to gcov. R=vogelheim@chromium.org Review URL: https://codereview.chromium.org/1529763002 Cr-Commit-Position: refs/heads/master@{#32859}
-
baptiste.afsa authored
Implement machine instruction scheduling after instruction selection. Currently only works for arm64. R=danno@chromium.org, bmeurer@chromium.org, titzer@chromium.org Review URL: https://codereview.chromium.org/1375253002 Cr-Commit-Position: refs/heads/master@{#32858}
-