| commit | 302c9ead4a0658fa9276b19333393e47d99bf19f | |
| author | Shaunak Kishore <kshaunak@fb.com> | |
| Wed, 9 Dec 2020 18:35:37 +0000 (9 10:35 -0800) | ||
| committer | Facebook GitHub Bot <facebook-github-bot@users.noreply.github.com> | |
| Wed, 9 Dec 2020 18:37:39 +0000 (9 10:37 -0800) | ||
| tree | 455e98bcb19e46d61b3e3ef3b2072cd9cb9bd102 | treesnapshot (tar.gz zip) |
| parent | 6bfddb55f87243fc40bdfc6329973ae4a59ecf0f | commitdiff |
Simplify iter_next native helpers
Summary:
These helpers were all extremely picky about dec-ref ordering, presumably from some time when that had consequences. We can now eliminate all of the "cold" tail-call helpers caused by that care, and we can even dec-ref the old value before setting the new value (which generally improves register usage). The last bit is possible because any new value that we set has at least one refcount held in the array itself.
I'm cleaning up these functions now because I'm going to introduce at least two new ones - for monotype vecs and dicts - and we're going to be using all of them more soon when we enable bespoke array-likes (which causes some iterators to be de-specialized).
In the same diff, I mostly try to rewrite the functions to look "parallel" (i.e. do the same operations in the same order) and to get rid of unnecessary cruft like ALWAYS_INLINE. But I'm afraid we do need inlining hints when we actually call a destructor - gcc will pretty much always eagerly inline those, and that regularly seems to cause regressions.
Reviewed By: ricklavoie
Differential Revision: D25383925
fbshipit-source-id: 15ab6742d29f4e618d4747898743f11a6863f39c
Summary:
These helpers were all extremely picky about dec-ref ordering, presumably from some time when that had consequences. We can now eliminate all of the "cold" tail-call helpers caused by that care, and we can even dec-ref the old value before setting the new value (which generally improves register usage). The last bit is possible because any new value that we set has at least one refcount held in the array itself.
I'm cleaning up these functions now because I'm going to introduce at least two new ones - for monotype vecs and dicts - and we're going to be using all of them more soon when we enable bespoke array-likes (which causes some iterators to be de-specialized).
In the same diff, I mostly try to rewrite the functions to look "parallel" (i.e. do the same operations in the same order) and to get rid of unnecessary cruft like ALWAYS_INLINE. But I'm afraid we do need inlining hints when we actually call a destructor - gcc will pretty much always eagerly inline those, and that regularly seems to cause regressions.
Reviewed By: ricklavoie
Differential Revision: D25383925
fbshipit-source-id: 15ab6742d29f4e618d4747898743f11a6863f39c
| hphp/runtime/vm/iter.cpp | diffblobblamehistory |