[PATCH] D98963: [LoopVectorize] Change the identity element for FAdd

Dave Green via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Thu Mar 25 14:02:51 PDT 2021


dmgreen added a comment.

In D98963#2650421 <https://reviews.llvm.org/D98963#2650421>, @spatel wrote:

> In D98963#2650388 <https://reviews.llvm.org/D98963#2650388>, @dmgreen wrote:
>
>> It would presumably need to be SROA that added flags to phi's it created? I'm not sure where it would get that info from though.
>
> I'm not sure either. We might need to apply FMF to load, stores, and function args to fill the gap. Another option might be to back-propagate the FMF from the `fadd` to its phi operand:
>
>   %s.0 = phi float [ 0.000000e+00, %entry ], [ %add, %for.body ]
>   %add = fadd fast float %s.0, %0
>
> Not sure if there's some corner-case I'm overlooking, but I'm imagining something like what instcombine does to fill-in / restore no-wrap flags (and so the FMF setting could also happen in instcombine).

That sounds great. Sounds like it might be useful past just these reductions. So long as we can say that flags propagate like that, or come up with some rules for when they do.

What do you think for the context of this review? Is it best to have a go at adding that into instcombine, plus a fold to make phi + nsz + -0.0 use 0.0 instead. Or go with the initial version of this patch that just plumbs the nsz flag through and emits 0.0 for the nsz case?


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D98963/new/

https://reviews.llvm.org/D98963



More information about the llvm-commits mailing list