https://gcc.gnu.org/bugzilla/show_bug.cgi?id=128483
Hongtao Liu <liuhongt at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |liuhongt at gcc dot gnu.org
--- Comment #4 from Hongtao Liu <liuhongt at gcc dot gnu.org> ---
(In reply to Reshma Roy from comment #3)
> (In reply to Richard Biener from comment #2)
> > IMO a better fix would be to use LCM to common/place the CSEd loads since
> > that would avoid placing loads where it would be possibly not executed
> > before (so it avoids speculation). Unless speculating the loads was
> > intended.
>
> I agree. But from my understanding from the pass, it looks like the
> speculative load was intended. There is the following comment in the pass
> right before the function where the cse happens as below:
> "NB: We want to generate a pattern, which is executed only once, to
> cover the whole function. The LCM algorithm isn't appropriate here
> since it may place a pattern inside the loop. */"
> Hence, I am confused how we should approach this problem.
>
The comments is copied from remove_partial_avx_dependency.
When we were implementing remove_partial_avx_dependency, we had two approaches
on the table: using LCM to insert pxor instructions, or hoisting them up to the
dominator. Looking back, we should have caught that the LCM approach wasn't
hoisting some pxor instructions out of loops — probably because LCM saw those
branches as low-probability and decided not to bother. For x86_cse, LCM is
likely the better fit, and at the very least we should be factoring in profile
data.
3563 NB: We want to generate only a single vxorps to cover the whole
3564 function. The LCM algorithm isn't appropriate here since it may
3565 place a vxorps inside the loop. */
3566
3567static unsigned int
3568remove_partial_avx_dependency (void)
3569{
