- 10 Mar, 2015 2 commits
-
-
bmeurer authored
Provide an intrinsic %MathFloor / %_MathFloor that is used to optimize both Math.ceil and Math.floor, and use the JS inlining mechanism to inline Math.ceil into TurboFan code. Although we need to touch code outside of TurboFan to make this work, this does not affect the way we handle Math.ceil and/or Math.floor in CrankShaft, because for CrankShaft the old-style builtin function id based inlining still kicks in first. Once this solution is stabilized, we can use it for Math.floor as well. And once that is settled, we can establish it as the unified way to inline builtins, and get rid of the specialized builtin function id based inlining at some point. Note that "builtin" applies to basically every piece of internal JavaScript/intrinsics based code, so this also applies to the yet to be defined JavaScript based code stubs and handlers. BUG=v8:3953 LOG=n R=yangguo@chromium.org,svenpanne@chromium.org Review URL: https://codereview.chromium.org/990963003 Cr-Commit-Position: refs/heads/master@{#27086}
-
bmeurer authored
Context specialization enables inlining (at least currently it is the only enabler for inlining), but inlining enables more possibilities for context specialization. So we really need to run them together. This is especially important with the "module based builtins" that we're working towards. BUG=v8:3952 LOG=n Review URL: https://codereview.chromium.org/988423004 Cr-Commit-Position: refs/heads/master@{#27085}
-
- 09 Mar, 2015 30 commits
-
-
dcarney authored
since the old style weakness is slated for removal, we might as well reuse the name to limit confusion. additionally I simplified the callback type to a enum to either get internal field values or not this should be a non-breaking change with the exception of PhantomPersistentValueMap, which is unused. R=jochen@chromium.org, erikcorry@chromium.org BUG= Review URL: https://codereview.chromium.org/989153003 Cr-Commit-Position: refs/heads/master@{#27084}
-
balazs.kilvady authored
BUG= Review URL: https://codereview.chromium.org/988243004 Cr-Commit-Position: refs/heads/master@{#27083}
-
machenbach authored
BUG=chromium:464657 LOG=n TBR=jochen@chromium.org Review URL: https://codereview.chromium.org/990253002 Cr-Commit-Position: refs/heads/master@{#27082}
-
machenbach authored
BUG=chromium:464657 LOG=n Review URL: https://codereview.chromium.org/987063002 Cr-Commit-Position: refs/heads/master@{#27081}
-
svenpanne authored
Note that this is done only for consistency at this point in time. The change should probably have been in https://codereview.chromium.org/984963002/ already. BUG=v8:3947 LOG=n Review URL: https://codereview.chromium.org/992683002 Cr-Commit-Position: refs/heads/master@{#27080}
-
jochen authored
R=hpayer@chromium.org LOG=n BUG=none Review URL: https://codereview.chromium.org/990203002 Cr-Commit-Position: refs/heads/master@{#27079}
-
titzer authored
Rationale: separate the inputs and outputs of parsing + analysis from the business of compiling (i.e. generating machine code). BUG= Review URL: https://codereview.chromium.org/974213002 Cr-Commit-Position: refs/heads/master@{#27078}
-
marja authored
R=dslomov@chromium.org BUG= Review URL: https://codereview.chromium.org/977123002 Cr-Commit-Position: refs/heads/master@{#27077}
-
loislo authored
The original code always returned the first entry from RelocInfo that matched with bailout_id. But we may have a few different deopt reasons for one bailout_id. So we need to get the one which matches with a particular call from JumpTable. We can do this by checking not 'target_address' (it maps to bailout_id) but 'from' address which maps to a particular JumpTable entry. The test was reworked so it tests identical functions against different reasons. BUG=chromium:452067 LOG=n Review URL: https://codereview.chromium.org/984773003 Cr-Commit-Position: refs/heads/master@{#27076}
-
marja authored
Methods can refer to the class name. BUG=v8:3927 LOG=N Review URL: https://codereview.chromium.org/968263002 Cr-Commit-Position: refs/heads/master@{#27075}
-
yangguo authored
R=mstarzinger@chromium.org Review URL: https://codereview.chromium.org/991833002 Cr-Commit-Position: refs/heads/master@{#27074}
-
hpayer authored
After establishing the invariant that the store buffer always has valid slots after marking, the store buffer integrity check is not needed anymore. BUG=454157 LOG=n Review URL: https://codereview.chromium.org/990173002 Cr-Commit-Position: refs/heads/master@{#27073}
-
yangguo authored
R=jkummerow@chromium.org Review URL: https://codereview.chromium.org/990883002 Cr-Commit-Position: refs/heads/master@{#27072}
-
jarin authored
This slightly hacky change provides lazy deopt points for to-number conversions in binops: When we deopt from a to-number conversion, we create a frame state with the already-converted value(s) so that we do not repeat the side effect of the conversion. Embenchen numbers are below. It is not quite clear what happened to fasta - the hot code looks nearly identical. Current: EmbenchenBox2d(RunTime): 12746 ms. d8-master: EmbenchenBox2d(RunTime): 13861 ms. ----------- bullet.js Current: EmbenchenBullet(RunTime): 17680 ms. d8-master: EmbenchenBullet(RunTime): 19170 ms. ----------- copy.js Current: EmbenchenCopy(RunTime): 4939 ms. d8-master: EmbenchenCopy(RunTime): 4943 ms. ----------- corrections.js Current: EmbenchenCorrections(RunTime): 6639 ms. d8-master: EmbenchenCorrections(RunTime): 6728 ms. ----------- fannkuch.js Current: EmbenchenFannkuch(RunTime): 4630 ms. d8-master: EmbenchenFannkuch(RunTime): 4872 ms. ----------- fasta.js Current: EmbenchenFasta(RunTime): 10209 ms. d8-master: EmbenchenFasta(RunTime): 9673 ms. ----------- lua_binarytrees.js Current: EmbenchenLuaBinaryTrees(RunTime): 12936 ms. d8-master: EmbenchenLuaBinaryTrees(RunTime): 15529 ms. ----------- memops.js Current: EmbenchenMemOps(RunTime): 7357 ms. d8-master: EmbenchenMemOps(RunTime): 7340 ms. ----------- primes.js Current: EmbenchenPrimes(RunTime): 7530 ms. d8-master: EmbenchenPrimes(RunTime): 7457 ms. ----------- skinning.js Current: EmbenchenSkinning(RunTime): 15832 ms. d8-master: EmbenchenSkinning(RunTime): 15630 ms. ----------- zlib.js Current: EmbenchenZLib(RunTime): 11176 ms. d8-master: EmbenchenZLib(RunTime): 11324 ms. BUG= Review URL: https://codereview.chromium.org/985713003 Cr-Commit-Position: refs/heads/master@{#27071}
-
mstarzinger authored
This makes sure only the %_DeoptimizeNow intrinsic is inlined, and not the %DeoptimizeNow one. It hence re-establishes the invariant that JSIntrinsicLowering only deals with inline intrinsics. R=jarin@chromium.org TEST=mjsunit/compiler/eager-deopt-simple Review URL: https://codereview.chromium.org/988333003 Cr-Commit-Position: refs/heads/master@{#27070}
-
Benedikt Meurer authored
The JSInliner used to load the context from the JSFunction node at runtime, which introduced a HeapConstant (because we had to materialize the JSFunction after context specialization) and a LoadField operation, independent whether the inlinee actually uses the context. This is rather cumbersome currently, and therefore this is now changed to just embed the context constant instead. Once we do inlining based on SharedFunctionInfo rather than JSFunction, we should reconsider this decision and come up with a proper heuristic. BUG=v8:3952 LOG=n R=mstarzinger@chromium.org Review URL: https://codereview.chromium.org/994523002 Cr-Commit-Position: refs/heads/master@{#27069}
-
hpayer authored
The store buffer can contain stale store buffer entries, i.e., slot in dead objects pointing to new space objects. These slots are treaded as live slots which cause problems with non-pointer fields and makes concurrent sweeping complicated. Removing these pointers from the store buffer before it is used makes life easier. BUG= Review URL: https://codereview.chromium.org/985453003 Cr-Commit-Position: refs/heads/master@{#27068}
-
verwaest authored
Revert of Store the next serial number in the function cache rather than in the isolate.Don't overwrite existi (patchset #4 id:60001 of https://codereview.chromium.org/988693003/) Reason for revert: This doesn't do what it's supposed to do. The problem seems to lie on the blink side, people aren't reusing their FunctionTemplates (or creating them when not necessary). Original issue's description: > Don't overwrite existing serial numbers on the function template, otherwise instantiating the function for a new context causes the serial number to bump. > > Committed: https://crrev.com/1e638c3610ec6938e5fb16c42018642195782fb2 > Cr-Commit-Position: refs/heads/master@{#27048} TBR=yangguo@chromium.org,dcarney@chromium.org NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true Review URL: https://codereview.chromium.org/993533003 Cr-Commit-Position: refs/heads/master@{#27067}
-
dcarney authored
BUG= Review URL: https://codereview.chromium.org/988283003 Cr-Commit-Position: refs/heads/master@{#27066}
-
Benedikt Meurer authored
Avoid loading the stack pointer and the stack limit into allocatable registers first, but generate a cmp rsp,[limit] instead. R=dcarney@chromium.org Review URL: https://codereview.chromium.org/989203002 Cr-Commit-Position: refs/heads/master@{#27065}
-
Jaroslav Sevcik authored
BUG=chromium:460937 R=ishell@chromium.org LOG=n Review URL: https://codereview.chromium.org/989093002 Cr-Commit-Position: refs/heads/master@{#27064}
-
ishell@chromium.org authored
Revert of Remove slots that point to unboxed doubles from the StoreBuffer/SlotsBuffer. (patchset #4 id:230001 of https://codereview.chromium.org/957273002/) Reason for revert: It caused a lot of Canary crashes. Original issue's description: > Remove slots that point to unboxed doubles from the StoreBuffer/SlotsBuffer. > > The problem is that tagged slot could become a double slot after migrating of an object to another map with "shifted" fields (for example as a result of generalizing immutable data property to a data field). > This CL also adds useful machinery that helps triggering incremental write barriers. > > BUG=chromium:454297 > LOG=Y > > Committed: https://crrev.com/9633ebabd405c264d33f603f8798c31f59418dcd > Cr-Commit-Position: refs/heads/master@{#27054} TBR=verwaest@chromium.org,hpayer@chromium.org NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true BUG=chromium:454297 Review URL: https://codereview.chromium.org/991793002 Cr-Commit-Position: refs/heads/master@{#27063}
-
Benedikt Meurer authored
Include what you use, and move implementation details to .cc file. R=svenpanne@chromium.org Review URL: https://codereview.chromium.org/986243002 Cr-Commit-Position: refs/heads/master@{#27062}
-
Dan Carney authored
BUG= R=svenpanne@chromium.org Review URL: https://codereview.chromium.org/990873002 Cr-Commit-Position: refs/heads/master@{#27061}
-
Jaroslav Sevcik authored
BUG= R=bmeurer@chromium.org Review URL: https://codereview.chromium.org/983153002 Cr-Commit-Position: refs/heads/master@{#27060}
-
Benedikt Meurer authored
We mark certain builtins for inlining, and those should always be inlined into optimized code (CrankShaft already handles it this way), so we should support that in TurboFan as well. Currently this mainly affects a certain set of Math functions, but once have the basics in place we can extend this to any kind of builtin/code stub/accessor. This adds a new flag --turbo_builtin_inlining (enabled by default), that forces the inliner to always inline builtins marked for inlining, but does not affect inlining of other functions (this is still controlled by the --turbo-inlining flag). BUG=v8:3952 LOG=n R=jarin@chromium.org Review URL: https://codereview.chromium.org/993473002 Cr-Commit-Position: refs/heads/master@{#27059}
-
Benedikt Meurer authored
This is currently the cleanest approach to avoid the useless stack check during inlining. We might be able to just remove the useless stack checks later when we have a phase that also takes care of removing redundant stack checks on loop back edges (which we do not generate currently). On the other hand, the flag introduced here might be useful when building code stubs/builtins/dom stubs using JS based DSL, because you certainly don't want a JS-level stack check in a code stub. R=jarin@chromium.org BUG=v8:3952 LOG=n Review URL: https://codereview.chromium.org/994433002 Cr-Commit-Position: refs/heads/master@{#27058}
-
Benedikt Meurer authored
Loading the coefficients from a the constants typed array is currently blocking inlining MathSin and MathCos into TurboFan generated code, because there is no type feedback and hence TurboFan has to generate a LOAD_IC for every coefficient. R=yanggou@chromium.org BUG=v8:3952 LOG=n Review URL: https://codereview.chromium.org/989133002 Cr-Commit-Position: refs/heads/master@{#27057}
-
Benedikt Meurer authored
The key idea here is that the stack check should be explicit, such that we can eliminate unnecessary stack checks after graph building and potentially inlining. R=mstarzinger@chromium.org Review URL: https://codereview.chromium.org/981243002 Cr-Commit-Position: refs/heads/master@{#27056}
-
Weiliang Lin authored
BUG= R=jkummerow@chromium.org Review URL: https://codereview.chromium.org/966773005 Cr-Commit-Position: refs/heads/master@{#27055}
-
- 06 Mar, 2015 8 commits
-
-
ishell authored
The problem is that tagged slot could become a double slot after migrating of an object to another map with "shifted" fields (for example as a result of generalizing immutable data property to a data field). This CL also adds useful machinery that helps triggering incremental write barriers. BUG=chromium:454297 LOG=Y Review URL: https://codereview.chromium.org/957273002 Cr-Commit-Position: refs/heads/master@{#27054}
-
Michael Achenbach authored
Cr-Commit-Position: refs/heads/master@{#27053}
-
rmcilroy authored
Revert of Revert of Revert of Turn on job based recompilation (patchset #1 id:1 of https://codereview.chromium.org/955723002/) Reason for revert: Breaks Octane on Arm64 running on Chrome. BUG=464538 Original issue's description: > Revert of Revert of Turn on job based recompilation (patchset #1 id:1 of https://codereview.chromium.org/937263004/) > > Reason for revert: > reland > > Original issue's description: > > Revert of Turn on job based recompilation (patchset #1 id:1 of https://codereview.chromium.org/935243003/) > > > > Reason for revert: > > waterfall disagrees > > > > Original issue's description: > > > Turn on job based recompilation > > > > > > BUG=v8:3608 > > > R=yangguo@chromium.org > > > LOG=y > > > > > > Committed: https://crrev.com/4ae82f64b09cdc0182cee3a5cc619a9117ac5fbc > > > Cr-Commit-Position: refs/heads/master@{#26826} > > > > TBR=yangguo@chromium.org > > NOPRESUBMIT=true > > NOTREECHECKS=true > > NOTRY=true > > BUG=v8:3608 > > > > Committed: https://crrev.com/35cc692aecdea54fb07479b8d7b71059851e07e8 > > Cr-Commit-Position: refs/heads/master@{#26827} > > TBR=yangguo@chromium.org > NOPRESUBMIT=true > NOTREECHECKS=true > NOTRY=true > BUG=v8:3608 > > Committed: https://crrev.com/3735a0851a9e2726f8b50a46a3bc770992328264 > Cr-Commit-Position: refs/heads/master@{#26829} TBR=yangguo@chromium.org,jochen@chromium.org NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true BUG=v8:3608 Review URL: https://codereview.chromium.org/984463003 Cr-Commit-Position: refs/heads/master@{#27052}
-
caitpotter88 authored
BUG= LOG=N R=arv@chromium.org Review URL: https://codereview.chromium.org/982153003 Cr-Commit-Position: refs/heads/master@{#27051}
-
dusan.milosavljevic authored
TEST= BUG= Review URL: https://codereview.chromium.org/987653005 Cr-Commit-Position: refs/heads/master@{#27050}
-
kalman authored
R=dcarney@chromium.org Review URL: https://codereview.chromium.org/986463005 Cr-Commit-Position: refs/heads/master@{#27049}
-
verwaest authored
Don't overwrite existing serial numbers on the function template, otherwise instantiating the function for a new context causes the serial number to bump. Review URL: https://codereview.chromium.org/988693003 Cr-Commit-Position: refs/heads/master@{#27048}
-
yangguo authored
Review URL: https://codereview.chromium.org/981213002 Cr-Commit-Position: refs/heads/master@{#27047}
-