1232360 - Do alias analysis for reserved slots

Status: RESOLVED INVALID

(Core :: JavaScript Engine, defect)

Description

[Michael Wu [:mwu]]

I heard alias analysis doesn't work on reserved slots. If not, it's probably good to have for self hosted js.

Comment 1

[Jan de Mooij [:jandem]]

(In reply to Michael Wu [:mwu] from comment #0)
> I heard alias analysis doesn't work on reserved slots.

That's not correct; to access reserved slots, we use the normal MIR instructions to load/store fixed/dynamic slots and alias analysis handles those just fine. AFAIK.

Comment 2

[Till Schneidereit [:till]]

nbp, I'm pretty sure you said something along the lines of this bug. I might well have misunderstood, but in case I didn't, can you clarify what you meant?

Comment 3

[Jeff Walden [:Waldo]]

We still have space in AliasSet::flags_ -- we could put fixed slot numbers in alias info if we wanted.  Access to a slot 0 never aliases access to a slot 1, right?  Could be a simple win.

Comment 4

[Eric Faust [:efaust]]

Maybe we meant "do per-slot alias analysis"? What we hope for is much more specificity, so that sets to slot 0 don't alias reads from slot 1 from the same object. Accessors make it hard to do this in general for object properties, but maybe it's doable for reserved slots.

Comment 5

[Eric Faust [:efaust]]

Ah, mid-air'd

(In reply to Jeff Walden [:Waldo] (remove +bmo to email) from comment #3)
> We still have space in AliasSet::flags_ -- we could put fixed slot numbers
> in alias info if we wanted.  Access to a slot 0 never aliases access to a
> slot 1, right?  Could be a simple win.

There's clearly not enough room for objects with big numbers of reserved slots, though, right? Like the global object, for example, has hundreds.

Comment 6

[Jan de Mooij [:jandem]]

(In reply to Jeff Walden [:Waldo] (remove +bmo to email) from comment #3)
> We still have space in AliasSet::flags_ -- we could put fixed slot numbers
> in alias info if we wanted.  Access to a slot 0 never aliases access to a
> slot 1, right?  Could be a simple win.

We already have a mechanism for that, see MLoadFixedSlot::mightAlias et al.

Comment 7

[Jeff Walden [:Waldo]]

(In reply to Eric Faust [:efaust] from comment #5)
> There's clearly not enough room for objects with big numbers of reserved
> slots, though, right? Like the global object, for example, has hundreds.

1) I said "fixed" slots, so there aren't hundreds to consider, at least as I conservatively described it.  ;-)
2) But, there's no reason you can't consider reserved slots -- that was just my being off-the-cuff over-conservative.  You just need to have an upper bound, then past that you treat it as an undistinguished slot-access that aliased all fixed slots and all reserved slots.  Deoptimizing slot-N access for large N for an object with Bunches of slots to alias everything seems totally tolerable.  (And, I think we have enough bits handy -- like ~20 or so -- that we'd cover slot numbers even for globals.)

Comment 8

[Nicolas B. Pierron [:nbp]]

As Jandem confirm, as the code confirms, we do compute some alias analysis on the reserve slot, as they are encoded as fixed slot. (=> RESOLVED INVALID)

The problem I was thinking of is about the Array[@@iterator] function, which creates an iterator structure which uses reserved slots.  Reserved slots have no type information associated to them, as we only keep type information on property names.

Then we have an optimization issue, where Array[@@iterator] in unlikely to be inlined, and Scalar Replacement of Object does not see the allocation of such object.  This implies that we cannot move the "iterator" to a register (without adding Scalar Replacement of Properties), thus we cannot do bounds checks on the value of the "iterator" with range analysis.

If we were to flag Array[@@iterator] function's returned values as newly-allocated & non-escaped, then we might be able to play a bit more with Scalar Replacement :)