[PATCH] D98708: [LoopVectorize] relax FMF constraint for FP induction

Sanjay Patel via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Wed Mar 17 05:30:21 PDT 2021


spatel added a comment.

In D98708#2631295 <https://reviews.llvm.org/D98708#2631295>, @david-arm wrote:

> Hi @dmgreen, yes of course you're right. I'd forgotten about the nsz requirement. It's definitely needed at compile time for vectorising FP reduction loops, i.e. `clang -freassociative-math -fno-trapping-math -fno-signed-zeroes`. I guess adding a check for nsz here is consistent with that?

Yes - clang derived its requirements from gcc, so we've passed that into the optimizer in some places (instcombine at least). I don't know of any practical examples where you could have FP reassociation and still guarantee sign-of-zero, but maybe I'm not being imaginative. :)
So currently there's no easy way (starting from C/C++ at least) to have IR that has `reassoc` without `nsz`.

Ok if I push this change, so we're consistent within the vectorizer? Then, I'll push a follow-up (we'll need a pile of new regression tests) to add the `nsz` requirement for both induction and reduction. That way, we'll be conservatively correct in requiring the extra flag, and we'll match the expected IR coming out of clang.

Note that the FMF requirements for fmul/fadd reduction/induction are different than the fmin/fmax patterns that we've also recently updated; fmin/fmax require `nnan` and `nsz` to rearrange, but not `reassoc` (since there's no FP math involved in those ops).


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

https://reviews.llvm.org/D98708



More information about the llvm-commits mailing list