https://gcc.gnu.org/bugzilla/show_bug.cgi?id=127086
Jeffrey A. Law <law at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Last reconfirmed| |2026-09-01
Ever confirmed|0 |1
Status|UNCONFIRMED |NEW
--- Comment #3 from Jeffrey A. Law <law at gcc dot gnu.org> ---
VXRM hoisting is based on an LCM algorithm. Baked into that algorithm is a
hard requirement that you can never introduce an expression on a path that
didn't have one before.
That constraint is extremely painful, particularly for pixel_avg. So we've
hacked up some code recognize the special case where a function needs a single
VXRM mode and that single VXRM mode can be set in the prologue with its value
surviving to the use points. The net of this little hack is in the most
important cases we saw the VXRM assignment would get hoisted up to the
prologue.
We were aware of the other VXRM cases inside x264. IIRC in that other case
there's a function call in the IL -- which implicitly clobbers VXRM state.
When I looked at our data those cases weren't hot at all, so we never tried to
further improve the little hack we did for pixel_avg.
The little hack could be conceptually adjusted to cover more cases. But I'd
suggest making sure the code in question is hot enough to be worth the
implementation/maintenance worth it.
Look at a65e1487cda969e4763ae84577bf3e0d9e2b34aa for further details.
