Bug 177806 – [FTL] Add feature to delay materialization when OSR exit occurs if node is only used by MovHint

• Status: NEW
• Component: JavaScriptCore

[Yusuke Suzuki]

We would like to extend Object Allocation Sinking (OAS) phase to the other operations that does not have side effect.
By doing so, we can eliminate these operations even if it is pointed by object properties or MovHint.

The thing in my mind is UInt32ToNumber, which can remain due to MovHint. But it can be removed if we leverage escape analysis done in OAS, by introducing PhantomUInt32ToNumber node.
So, we would like to extend OAS to handle nodes other than allocations.

I would like to introduce this change separately from bug 177281 since bug 177281 is a bit large and it already handles things seen in emscripten well.

[Yusuke Suzuki]

(In reply to Yusuke Suzuki from comment #0)
> We would like to extend Object Allocation Sinking (OAS) phase to the other
> operations that does not have side effect.
> By doing so, we can eliminate these operations even if it is pointed by
> object properties or MovHint.
> 
> The thing in my mind is UInt32ToNumber, which can remain due to MovHint. But
> it can be removed if we leverage escape analysis done in OAS, by introducing
> PhantomUInt32ToNumber node.
> So, we would like to extend OAS to handle nodes other than allocations.
> 
> I would like to introduce this change separately from bug 177281 since bug
> 177281 is a bit large and it already handles things seen in emscripten well.

Another target is MakeRope.

[Yusuke Suzuki]

(In reply to Yusuke Suzuki from comment #1)
> (In reply to Yusuke Suzuki from comment #0)
> > We would like to extend Object Allocation Sinking (OAS) phase to the other
> > operations that does not have side effect.
> > By doing so, we can eliminate these operations even if it is pointed by
> > object properties or MovHint.
> > 
> > The thing in my mind is UInt32ToNumber, which can remain due to MovHint. But
> > it can be removed if we leverage escape analysis done in OAS, by introducing
> > PhantomUInt32ToNumber node.
> > So, we would like to extend OAS to handle nodes other than allocations.
> > 
> > I would like to introduce this change separately from bug 177281 since bug
> > 177281 is a bit large and it already handles things seen in emscripten well.
> 
> Another target is MakeRope.

And this reduces the burden of removing MovHint aggressively. Even in the face of conservative / sub-optimal MovHint elimination, we can still remove bunch of unnecessary materializations.

[Filip Pizlo]

That phase has so much complexity because it is escape-analyzing. You don’t have to escape analyze anything to use materialization to side-step MovHints during DCE. So, whatever you do, it should probably not be part of that phase.

[Yusuke Suzuki]

(In reply to Filip Pizlo from comment #3)
> That phase has so much complexity because it is escape-analyzing. You don’t
> have to escape analyze anything to use materialization to side-step MovHints
> during DCE. So, whatever you do, it should probably not be part of that
> phase.

Is it better to have a new phase for this optimization?

[Filip Pizlo]

(In reply to Yusuke Suzuki from comment #4)
> (In reply to Filip Pizlo from comment #3)
> > That phase has so much complexity because it is escape-analyzing. You don’t
> > have to escape analyze anything to use materialization to side-step MovHints
> > during DCE. So, whatever you do, it should probably not be part of that
> > phase.
> 
> Is it better to have a new phase for this optimization?

Yeah!  Go ahead and add a new phase!

Another reason to add a new phase: ObjectAllocationSinking is the single most expensive phase, so we probably want to rethink some of its data structures. If it was also tracking pure operations, it would be even more expensive. 

But fundamentally: object allocation sinking is running a must-points-to analysis. You don’t need that.

[Yusuke Suzuki]

(In reply to Filip Pizlo from comment #5)
> (In reply to Yusuke Suzuki from comment #4)
> > (In reply to Filip Pizlo from comment #3)
> > > That phase has so much complexity because it is escape-analyzing. You don’t
> > > have to escape analyze anything to use materialization to side-step MovHints
> > > during DCE. So, whatever you do, it should probably not be part of that
> > > phase.
> > 
> > Is it better to have a new phase for this optimization?
> 
> Yeah!  Go ahead and add a new phase!
> 
> Another reason to add a new phase: ObjectAllocationSinking is the single
> most expensive phase, so we probably want to rethink some of its data
> structures. If it was also tracking pure operations, it would be even more
> expensive. 
> 
> But fundamentally: object allocation sinking is running a must-points-to
> analysis. You don’t need that.

OK, sounds reasonable! I'll create a new phase for that :)