https://gcc.gnu.org/bugzilla/show_bug.cgi?id=128483
--- Comment #5 from Reshma Roy <Reshma.Roy at amd dot com> ---
(In reply to Hongtao Liu from comment #4)
> (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{
Thanks for explaining. I will try a patch that uses LCM to place the
broadcasts (X86_CSE_VEC_DUP and X86_CSE_CONST_VECTOR) in x86_cse.
