[PATCH] D112117: [llvm][LV] Drop poison-generating flags from FP instructions

[Sanjay Patel via Phabricator via llvm-commits]

spatel added a comment.

I didn't go through all of the tests, but the first reduction expansion diff seems unintended to me (see inline comment). 
We could enable dropping FMF only with an optional bool parameter? That would allow incremental updates. 
Or we handle that as a one-off in the motivating LV caller?



================
Comment at: llvm/test/CodeGen/Generic/expand-experimental-reductions.ll:100
 entry:
   %r = call fast float @llvm.vector.reduce.fadd.f32.v4f32(float 0.0, <4 x float> %vec)
   ret float %r
----------------
This isn't the result that we want. This might be due to the vague definitions and interactions of FMF, but I think 'fast' should propagate through this expansion. 

For example, if the intrinsic has 'nnan reassoc', then we should be able say that the result is also 'nnan reassoc'. That is, we disallowed NAN inputs and allowed reassociation, so we can assume that a NAN was not accidentally/unknowingly created through this transform where it would not have been in the original code.

The use of dropPoison for integer ops in the ExpandReductions pass is correct though...


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D112117