Turboshaft LICM

143 views
Skip to first unread message

Sam Parker-Haynes

unread,
Aug 29, 2024, 8:35:46 AM8/29/24
to v8-dev
Hi,

I've been looking at some regressions when moving from Turbofan to Turboshaft and I've noticed loop-invariant code being left inside loops generated from Turboshaft. I assume this was something that came for free with the sea-of-nodes..?

Looking at the existing reducers, the copying-phase and variable-reducer seem as if they have the necessary parts to enable a loop-invariant-code-motion reducer to be simple enough. Does this sound about right..?

One, little, thing is that I still don't really understand the whole input/output graph mechanics... Is there something I could read or could someone explain? Maybe in the context of moving operations out of a loop :)

cheers,
sam

Jakob Kummerow

unread,
Aug 29, 2024, 9:43:19 AM8/29/24
to v8-...@googlegroups.com
Hi Sam,

Just a quick comment: yes, we want LICM for Turboshaft, but it's not quite the right time to implement it: before adding more risk via additional optimizations, we need to ship what we have, that's turned out to be difficult enough.

The status quo is that we rely on Loop Peeling plus subsequent Load Elimination and GVN, but we know that there are cases where we decide not to peel but would nevertheless like to hoist some stuff out of the loop. On the flip side, when it does trigger, the current strategy is more powerful: operations that can throw (JS) or trap (Wasm) cannot be LICM'ed (because the loop could run for zero iterations in practice), but they can be deduplicated after Peeling.

Of course, it's always a good time to learn how stuff works, so I don't want to discourage that :-)

Cheers,
Jakob

Sam Parker-Haynes

unread,
Aug 30, 2024, 9:39:54 AM8/30/24
to v8-dev
Hi Jakob,

Thanks for the explanation. I can certainly see how that approach is powerful, but it also sounds likely overkill for simple operations :)

There's also the, reasonable, limitation of only peeling inner loops. I guess this approach can lead to peeling operations, which are still invariant to the parent loop yet reside inside? Or is there some other magic that happens? It's just that I see the VariableReducer and VariableData having a concept of loop invariance, so I was wondering how that is used.

cheers,
Sam
Reply all
Reply to author
Forward
0 new messages