- 13 Aug, 2015 1 commit
-
-
mstarzinger authored
This tries to remove includes of "-inl.h" headers from normal ".h" headers, thereby reducing the chance of any cyclic dependencies and decreasing the average size of our compilation units. Note that this change still leaves 5 violations of that rule in the code. It only tackles "node.h" including "types-inl.h". R=titzer@chromium.org Review URL: https://codereview.chromium.org/1288053004 Cr-Commit-Position: refs/heads/master@{#30161}
-
- 06 Jul, 2015 3 commits
-
-
bmeurer authored
[turbofan] Reland "Add new JSFrameSpecialization reducer." and "Perform OSR deconstruction early and remove type propagation.". We have to reland these two commits at once, because the first breaks some asm.js benchmarks without the second. The change was reverted because of bogus checks in the verifier, which will not work in the presence of OSR (and where hidden because of the type back propagation hack in OSR so far). Original messages are below: [turbofan] Add new JSFrameSpecialization reducer. The JSFrameSpecialization specializes an OSR graph to the current unoptimized frame on which we will perform the on-stack replacement. This is used for asm.js functions, where we cannot reuse the OSR code object anyway because of context specialization, and so we could as well specialize to the max instead. It works by replacing all OsrValues in the graph with their values in the JavaScriptFrame. The idea is that using this trick we get better performance without doing the unsound backpropagation of types to OsrValues later. This is the first step towards fixing OSR for TurboFan. [turbofan] Perform OSR deconstruction early and remove type propagation. This way we don't have to deal with dead pre-OSR code in the graph and risk optimizing the wrong code, especially we don't make optimistic assumptions in the dead code that leaks into the OSR code (i.e. deopt guards are in dead code, but the types propagate to OSR code via the OsrValue type back propagation). BUG=v8:4273 LOG=n R=jarin@chromium.org Review URL: https://codereview.chromium.org/1226673005 Cr-Commit-Position: refs/heads/master@{#29486}
-
machenbach authored
Also revert "[turbofan] Perform OSR deconstruction early and remove type propagation." This reverts commit b0a852e8. This reverts commit cdbb6c48. NOTRY=true NOTREECHECKS=true BUG=v8:4273 LOG=n TBR=bmeurer@chromium.org Review URL: https://codereview.chromium.org/1225743002 Cr-Commit-Position: refs/heads/master@{#29480}
-
bmeurer authored
The JSFrameSpecialization specializes an OSR graph to the current unoptimized frame on which we will perform the on-stack replacement. This is used for asm.js functions, where we cannot reuse the OSR code object anyway because of context specialization, and so we could as well specialize to the max instead. It works by replacing all OsrValues in the graph with their values in the JavaScriptFrame. The idea is that using this trick we get better performance without doing the unsound backpropagation of types to OsrValues later. This is the first step towards fixing OSR for TurboFan. R=jarin@chromium.org BUG=v8:4273 LOG=n Review URL: https://codereview.chromium.org/1225683004 Cr-Commit-Position: refs/heads/master@{#29476}
-