[PATCH] D118426: [InstCombine] Remove side effect of replaced constrained intrinsics

[Kevin P. Neal via Phabricator via llvm-commits]

kpn added a comment.

I'm still not clear on why, when a transform pass knows an instruction can be deleted, we are required to keep that instruction around anyway. It seems like these dangling, useless instructions would interfere with subsequent optimizations until finally they might or might not get removed here. And constant folding isn't sufficient to duplicate the logic of the transform pass that determined the instruction could be deleted.

For example, here's a small test that I'm working on for InstSimplify:

; NOTE: The fsub instruction is expected to remain, but the result isn't used.
define float @nonneg_ebstrict(i32 %a) #0 {

  %fpa = call float @llvm.experimental.constrained.uitofp.f32.i32(i32 %a, metadata !"round.tonearest", metadata !"fpexcept.strict") #0
  %sqra = call float @llvm.experimental.constrained.sqrt.f32(float %fpa, metadata !"round.tonearest", metadata !"fpexcept.strict") #0
  %sub = call nnan float @llvm.experimental.constrained.fsub.f32(float %sqra, float -0.0, metadata !"round.tonearest", metadata !"fpexcept.strict") #0
  ret float %sub

}

The input to the sqrt instruction will always be non-negative, so we know the output is valid, and we know the output will never be -0.0. This means the fsub can be safely eliminated. But the fsub will hang around forever, useless, because InstSimplify isn't allowed to tell anyone that it can be deleted, and nobody else can determine it again without duplicating InstSimplify.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D118426