Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Implement PPCBC: optimize the shizznick out of BaselineCompiler #245

Closed
GoogleCodeExporter opened this issue Aug 9, 2015 · 8 comments
Closed

Comments

@GoogleCodeExporter
Copy link
Contributor

Part 1: optimize int32 and boolean multi-type guards
Part 2: optimize object and string or int32 multi-type guards
Part 3: optimize object and shape/clasp guards
Part 4: optimize double guards

Part 1 is already implemented. 6% improvement on V8.

Original issue reported on code.google.com by [email protected] on 11 Oct 2013 at 4:27

@GoogleCodeExporter
Copy link
Contributor Author

Original comment by [email protected] on 11 Oct 2013 at 4:27

@GoogleCodeExporter
Copy link
Contributor Author

original V8: 282 avg
after part 1: 299 avg
after part 2: 318 avg

Original comment by [email protected] on 11 Oct 2013 at 4:36

@GoogleCodeExporter
Copy link
Contributor Author

Part 3 will have to be much more limited. It occurred to me that if the payload 
is not an object pointer, then we could be off in never-never-land with 
unmapped memory trying to speculatively identify its shape or clasp.

Original comment by [email protected] on 12 Oct 2013 at 4:26

@GoogleCodeExporter
Copy link
Contributor Author

Part 4 won't work. There is no fast path for double conversion; most of the 
time they have to go through conversion. We end up doing less work if we just 
test in the beginning rather than trying to make the guard clever. It reduced 
Crypto by 15% and didn't help RayTrace.

Part 5: optimize string guards. No improvement, but no regression. Might help 
more for string heavy ops like the browser and Peacekeeper, though. Still at 
318 avg score.

Original comment by [email protected] on 12 Oct 2013 at 7:53

@GoogleCodeExporter
Copy link
Contributor Author

Part 6: change truthy testing for int32 and string to straight line sequences. 
Changes relatively little, but Splay jumped 30 points. 320 avg score.

Original comment by [email protected] on 12 Oct 2013 at 11:50

@GoogleCodeExporter
Copy link
Contributor Author

Speculatively looking at whether adding additional straightline sequences for 
boolean ops in BaselineIC-ppc showed the existing ones get hit exclusively, and 
even then not that much.

We may have hit the wall for the time being.

Original comment by [email protected] on 13 Oct 2013 at 12:02

@GoogleCodeExporter
Copy link
Contributor Author

We're shipping. Further work to occur on Ion.

Original comment by [email protected] on 17 Oct 2013 at 3:46

@GoogleCodeExporter
Copy link
Contributor Author

Original comment by [email protected] on 17 Oct 2013 at 3:46

  • Changed state: Verified

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant