- 28 Jan, 2016 18 commits
-
-
yangguo authored
ES2015 Annex B.1.4 specifies a restricted pattern language for unicode mode. This change reflects that, based on some test262 test cases. R=littledan@chromium.org BUG=v8:2952 LOG=N Review URL: https://codereview.chromium.org/1645573002 Cr-Commit-Position: refs/heads/master@{#33584}
-
ivica.bogosavljevic authored
Revert of MIPS: Add FPXX support to MIPS32R2 (patchset #3 id:40001 of https://codereview.chromium.org/1586223004/ ) Reason for revert: Revert patch due to a number of failures appearing on the MIPS v8 simulator Original issue's description: > MIPS: Add FPXX support to MIPS32R2 > > The JIT code generated by V8 is FPXX compliant > when v8 compiled with FPXX flag. This allows the code to > run in both FP=1 and FP=0 mode. It also alows v8 to be used > as a library by both FP32 and FP64 binaries. > > BUG= > > Committed: https://crrev.com/95110dde666158a230a823fd50a68558ad772320 > Cr-Commit-Position: refs/heads/master@{#33576} TBR=paul.lind@imgtec.com,gergely.kis@imgtec.com,akos.palfi@imgtec.com,ilija.pavlovic@imgtec.com,marija.antic@imgtec.com,miran.karic@imgtec.com,balazs.kilvady@imgtec.com # 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/1646813003 Cr-Commit-Position: refs/heads/master@{#33583}
-
bmeurer authored
The previous versions of Math.max and Math.min made it difficult to optimize those (that's why we already have custom code in Crankshaft), and due to lack of ideas what to do about the variable number of arguments, we will probably need to stick in special code in TurboFan as well; so inlining those builtins is off the table, hence there's no real advantage in having them around as "not quite JS" with extra work necessary in the optimizing compilers to still make those builtins somewhat fast in cases where we cannot inline them (also there's a tricky deopt loop in Crankshaft related to Math.min and Math.max, but that will be dealt with later). So to sum up: Instead of trying to make Math.max and Math.min semi-fast in the optimizing compilers with weird work-arounds support %_Arguments %_ArgumentsLength, we do provide the optimal code as native builtins instead and call it a day (which gives a nice performance boost on some benchmarks). R=jarin@chromium.org Review URL: https://codereview.chromium.org/1641083003 Cr-Commit-Position: refs/heads/master@{#33582}
-
titzer authored
R=ahaas@chromium.org, bradnelson@chromium.org BUG= Review URL: https://codereview.chromium.org/1642043002 Cr-Commit-Position: refs/heads/master@{#33581}
-
mstarzinger authored
This translates the exception handler table attached to a bytecode array correctly into exceptional projections within the TurboFan graph. We perform an abstract simulation of handlers that are being entered and exited by the bytecode iteration to track the correct handler for each node. R=oth@chromium.org BUG=v8:4674 LOG=n Review URL: https://codereview.chromium.org/1641723002 Cr-Commit-Position: refs/heads/master@{#33580}
-
yangguo authored
This change adds AbstractCode, which can be either Code or BytecodeArray, and adds methods to calculate source position based on that. Also cleans up to use code offsets instead of raw PC where possible, and consistently uses the offset from instruction start (as opposed to code object start). R=rmcilroy@chromium.org, vogelheim@chromium.org BUG=v8:4690 LOG=N Review URL: https://codereview.chromium.org/1618343002 Cr-Commit-Position: refs/heads/master@{#33579}
-
bangfu.tao authored
BUG= A bug in android-sync.sh, which caused the android_arm.release.check unittests crash on device. It is fixed by adding: sync_file "$OUTDIR/$ARCH_MODE/natives_blob.bin" sync_file "$OUTDIR/$ARCH_MODE/snapshot_blob.bin" Review URL: https://codereview.chromium.org/1616393002 Cr-Commit-Position: refs/heads/master@{#33578}
-
bmeurer authored
R=mstarzinger@chromium.org Review URL: https://codereview.chromium.org/1647653004 Cr-Commit-Position: refs/heads/master@{#33577}
-
ivica.bogosavljevic authored
The JIT code generated by V8 is FPXX compliant when v8 compiled with FPXX flag. This allows the code to run in both FP=1 and FP=0 mode. It also alows v8 to be used as a library by both FP32 and FP64 binaries. BUG= Review URL: https://codereview.chromium.org/1586223004 Cr-Commit-Position: refs/heads/master@{#33576}
-
hpayer authored
This currently works since we never call set_target_cell when we have to record slots for evacuation. It would break with black allocation. BUG=chromium:561449 LOG=n Review URL: https://codereview.chromium.org/1643573003 Cr-Commit-Position: refs/heads/master@{#33575}
-
neis authored
The body of a generator function can now refer to the generator's input value via a new "function.sent" expression. We extend the proposal at https://github.com/allenwb/ESideas/blob/master/Generator%20metaproperty.md in the obvious way to also apply to GeneratorResumeAbrupt. This will enable us to desugar yield*. The new syntax is behind a new --harmony-function-sent flag. BUG=v8:4700 LOG=n Review URL: https://codereview.chromium.org/1620253003 Cr-Commit-Position: refs/heads/master@{#33574}
-
zhengxing.li authored
X87 TurboFan code generation convention assumes that there is always a value at the top of the X87 FPU stack for each TurboFan's float operation. But native C++ function assumes there are 8 FPU stack slots can be used when it's called. This will lead to FPU stack overflow when TurboFan x87 code calls or returns back to native C++ function. as there are only 7 FPU stack slots remained for this native C++ function. This CL does: 1. Make sure X87 FPU stack depth always 1 before each TurboFan's float operation 2. Remove the top value in X87 FPU stack required by TurboFan when calling or returning from TurboFan Functions to other TurboFan or Non-TurboFan Functions. 3. Add the strict X87 FPU stack depth check for TurboFan debug code. 4. Re-initialize the X87 FPU stack and push a value at the top of the X87 FPU stack to satify the X87 TurboFan code generation convention for float operation at the entries where the TurboFan code will be called such as: exception handler, CallCFunctions in tests,..etc BUG= Review URL: https://codereview.chromium.org/1636353002 Cr-Commit-Position: refs/heads/master@{#33573}
-
bmeurer authored
We can reduce Math.round(v) to a sequence of let i = Float64RoundUp(v); let r = i - v; return r > 0.5 ? 1.0 + i : i; if the target supports the Float64RoundUp machine operator (i.e. roundsd with RoundUp rounding on Intel processors with SSE4.1). R=jarin@chromium.org Review URL: https://codereview.chromium.org/1640393002 Cr-Commit-Position: refs/heads/master@{#33572}
-
bmeurer authored
We already have this fast case in Crankshaft where we don't call %ToInteger when the input is already a SMI. Add the same optimization to JSIntrinsicLowering. R=jarin@chromium.org Review URL: https://codereview.chromium.org/1641753002 Cr-Commit-Position: refs/heads/master@{#33571}
-
zhengxing.li authored
port 57d202d8 (r33550) original commit message: BUG= Review URL: https://codereview.chromium.org/1640823003 Cr-Commit-Position: refs/heads/master@{#33570}
-
v8-autoroll authored
Rolling v8/tools/clang to 50155e1a5a647a6184e3fe2c687e2fbe1720d3e4 TBR=machenbach@chromium.org,vogelheim@chromium.org,hablich@chromium.org Review URL: https://codereview.chromium.org/1639253004 Cr-Commit-Position: refs/heads/master@{#33569}
-
zhengxing.li authored
port a2baaaac (r33538) original commit message: BUG= Review URL: https://codereview.chromium.org/1644863002 Cr-Commit-Position: refs/heads/master@{#33568}
-
zhengxing.li authored
port a685180d (r33535) original commit message: On Intel, imul clobbers {r|e}ax. We're missing that in the representation of the MulHigh intermediate instructions. Fixing, by adding it as a temp, akin VisitDiv does. BUG= Review URL: https://codereview.chromium.org/1643753003 Cr-Commit-Position: refs/heads/master@{#33567}
-
- 27 Jan, 2016 22 commits
-
-
mbrandy authored
Port 57d202d8 R=yangguo@chromium.org, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com BUG=v8:2952 LOG=N Review URL: https://codereview.chromium.org/1646613002 Cr-Commit-Position: refs/heads/master@{#33566}
-
mbrandy authored
Port a2baaaac R=yangguo@chromium.org, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com BUG=v8:2952 LOG=N Review URL: https://codereview.chromium.org/1643683002 Cr-Commit-Position: refs/heads/master@{#33565}
-
alph authored
There might be more native functions at root node, e.g. b.CreateDoubleResultArray TBR=bmeurer@chromium.org Review URL: https://codereview.chromium.org/1644663003 Cr-Commit-Position: refs/heads/master@{#33564}
-
mbrandy authored
Constant pool must be marked as unavailable for use after the caller's pointer has been restored ahead of the tail call. R=joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com, ishell@chromium.org BUG= Review URL: https://codereview.chromium.org/1641743002 Cr-Commit-Position: refs/heads/master@{#33563}
-
adamk authored
Note that in these cases, we don't support computed property names yet, just as we don't for object and class literals. BUG=v8:3699, v8:4710 LOG=n Review URL: https://codereview.chromium.org/1634403002 Cr-Commit-Position: refs/heads/master@{#33562}
-
jochen authored
R=yangguo@chromium.org BUG= Review URL: https://codereview.chromium.org/1641673002 Cr-Commit-Position: refs/heads/master@{#33561}
-
brucedawson authored
The VS 2013 toolchain used by v8 is ~two months out of date. The Chromium toolchain was updated in October to include the Windows 10 SDK. Using a different toolchain in v8 leads to the possibility of odd incompatibilities, and means that switching between Chromium and v8 requires a time-consuming reinstallation of the toolchain. The VS 2013 toolchain was updated by crrev.com/1502563003. The VS 2015 toolchain used by v8 is also out of date. It is the wrong compiler version (RTM instead of Update 1), the wrong SDK version, and it is missing files such as the UCRT installers. LOG=N BUG=440500,491424 Review URL: https://codereview.chromium.org/1632363002 Cr-Commit-Position: refs/heads/master@{#33560}
-
mstarzinger authored
This cleans up the aforementioned predicate to not rely on the flags computed for communication between compiled code and the runtime. The underlying predicates of the AST are used directly instead. R=mvstanton@chromium.org Review URL: https://codereview.chromium.org/1638353002 Cr-Commit-Position: refs/heads/master@{#33559}
-
alph authored
Safe stack iterator is supposed to work even when the stack is in an inconsistent state. E.g. during cpu profile sample recording. This patch eliminates a crash if the frame marker is found to be bogus. BUG=v8:4705 LOG=N Review URL: https://codereview.chromium.org/1633323002 Cr-Commit-Position: refs/heads/master@{#33558}
-
jochen authored
R=verwaest@chromium.org BUG= Review URL: https://codereview.chromium.org/1644603002 Cr-Commit-Position: refs/heads/master@{#33557}
-
mvstanton authored
Revert of Type Feedback Vector lives in the closure (patchset #2 id:20001 of https://codereview.chromium.org/1642613002/ ) Reason for revert: Bug: failing to use write barrier when writing code entry into closure. Original issue's description: > Reland of Type Feedback Vector lives in the closure > > (Fixed a bug found by nosnap builds.) > > We get less "pollution" of type feedback if we have one vector per native > context, rather than one for the whole system. This CL moves the vector > appropriately. > > We rely more heavily on the Optimized Code Map in the SharedFunctionInfo. The > vector actually lives in the first slot of the literals array (indeed there is > great commonality between those arrays, they can be thought of as the same > thing). So we make greater effort to ensure there is a valid literals array > after compilation. > > This meant, for performance reasons, that we needed to extend > FastNewClosureStub to support creating closures with literals. And ultimately, > it drove us to move the optimized code map lookup out of FastNewClosureStub > and into the compile lazy builtin. > > The heap change is trivial so I TBR Hannes for it... > > TBR=hpayer@chromium.org > BUG= > > Committed: https://crrev.com/d984b3b0ce91e55800f5323b4bb32a06f8a5aab1 > Cr-Commit-Position: refs/heads/master@{#33548} TBR=bmeurer@chromium.org,yangguo@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/1643533003 Cr-Commit-Position: refs/heads/master@{#33556}
-
marija.antic authored
Implement the optional turbofan operators Word32Ctz, Word64Ctz, Word32Popcnt and Word64Popcnt. BUG= Review URL: https://codereview.chromium.org/1588383002 Cr-Commit-Position: refs/heads/master@{#33555}
-
bmeurer authored
R=jarin@chromium.org BUG=v8:4583 LOG=n Review URL: https://codereview.chromium.org/1642653002 Cr-Commit-Position: refs/heads/master@{#33554}
-
akos.palfi authored
TEST=mjsunit/harmony/unicode-regexp-ignore-case BUG= Review URL: https://codereview.chromium.org/1639263002 Cr-Commit-Position: refs/heads/master@{#33553}
-
mlippautz authored
This reverts commit 85ba94f2. All parallelism can be turned off using --predictable, or --noparallel-compaction. This patch completely parallelizes - semispace copy: from space -> to space (within newspace) - newspace evacuation: newspace -> oldspace - oldspace compaction: oldspace -> oldspace Previously newspace has been handled sequentially (semispace copy, newspace evacuation) before compacting oldspace in parallel. However, on a high level there are no dependencies between those two actions, hence we parallelize them altogether. We base the number of evacuation tasks on the overall set of to-be-processed pages (newspace + oldspace compaction pages). Some low-level details: - The hard cap on number of tasks has been lifted - We cache store buffer entries locally before merging them back into the global StoreBuffer in a finalization phase. - We cache AllocationSite operations locally before merging them back into the global pretenuring storage in a finalization phase. - AllocationSite might be compacted while they would be needed for newspace evacuation. To mitigate any problems we defer checking allocation sites for newspace till merging locally buffered data. CQ_EXTRA_TRYBOTS=tryserver.v8:v8_linux_arm64_gc_stress_dbg,v8_linux_gc_stress_dbg,v8_mac_gc_stress_dbg,v8_linux64_asan_rel,v8_linux64_tsan_rel,v8_mac64_asan_rel BUG=chromium:524425 LOG=N R=hpayer@chromium.org, ulan@chromium.org Review URL: https://codereview.chromium.org/1640563004 Cr-Commit-Position: refs/heads/master@{#33552}
-
verwaest authored
BUG=chromium:580584 LOG=y Review URL: https://codereview.chromium.org/1632603002 Cr-Commit-Position: refs/heads/master@{#33551}
-
yangguo authored
R=erik.corry@gmail.com BUG=v8:2952 LOG=N Review URL: https://codereview.chromium.org/1630633002 Cr-Commit-Position: refs/heads/master@{#33550}
-
zhengxing.li authored
port 6131ab1e (r33509) original commit message: This CL implements PrepareForTailCall() mentioned in ES6 spec for full codegen, Crankshaft and Turbofan. When debugger is active tail calls are disabled. Tail calling can be enabled by --harmony-tailcalls flag. BUG= Review URL: https://codereview.chromium.org/1637163003 Cr-Commit-Position: refs/heads/master@{#33549}
-
mvstanton authored
(Fixed a bug found by nosnap builds.) We get less "pollution" of type feedback if we have one vector per native context, rather than one for the whole system. This CL moves the vector appropriately. We rely more heavily on the Optimized Code Map in the SharedFunctionInfo. The vector actually lives in the first slot of the literals array (indeed there is great commonality between those arrays, they can be thought of as the same thing). So we make greater effort to ensure there is a valid literals array after compilation. This meant, for performance reasons, that we needed to extend FastNewClosureStub to support creating closures with literals. And ultimately, it drove us to move the optimized code map lookup out of FastNewClosureStub and into the compile lazy builtin. The heap change is trivial so I TBR Hannes for it... TBR=hpayer@chromium.org BUG= Review URL: https://codereview.chromium.org/1642613002 Cr-Commit-Position: refs/heads/master@{#33548}
-
Michael Achenbach authored
Cr-Commit-Position: refs/heads/master@{#33547}
-
mvstanton authored
BUG= R=mstarzinger@chromium.org Review URL: https://codereview.chromium.org/1638333002 Cr-Commit-Position: refs/heads/master@{#33546}
-
mstarzinger authored
This ensures that the BytecodeGraphBuilder can generate correct graphs even when deoptimization has not been enabled. This configuration is not enabled in production, and we might eventually decide to deprecate it for good. Until then, this is a quick fix. R=jarin@chromium.org TEST=cctest/test-pipeline Review URL: https://codereview.chromium.org/1640683002 Cr-Commit-Position: refs/heads/master@{#33545}
-