[AMDGPU] CodeGen regressions after #154336

[jayfoad]

#154336 causes performance regressions in a few of our graphics benchmarks. From staring at some large before-and-after shader dumps it seems that the slower shaders simply have more computational instructions in them (v_mul_f32, v_fme_f32 and similar). I tried automatically reducing a test case and came up with: r.txt

$ opt -S -p=instcombine,scalarizer,instcombine < r.txt

Before #154336, all the math is removed and the function just returns poison. After #154336, none of the math is removed.

[llvmbot]

@llvm/issue-subscribers-backend-amdgpu

Author: Jay Foad (jayfoad)

#154336 causes performance regressions in a few of our graphics benchmarks. From staring at some large before-and-after shader dumps it seems that the slower shaders simply have more computational instructions in them (v_mul_f32, v_fme_f32 and similar). I tried automatically reducing a test case and came up with: [r.txt](https://github.com/user-attachments/files/23094138/r.txt) ``` $ opt -S -p=instcombine,scalarizer,instcombine < r.txt ``` Before #154336, all the math is removed and the function just returns `poison`. After #154336, none of the math is removed.

[jayfoad]

#164809 might help a bit with handling the llvm.amdgcn.fmul.legacy intrinsic in the test case.

[jayfoad]

Here's a tiny example:

define <3 x float> @main(<3 x float> %arg) {
  %mul = fmul <3 x float> %arg, <float poison, float 0.0, float poison>
  %fr = freeze <3 x float> %mul
  ret <3 x float> %fr
}

Before #154336 I get:

$ ./opt-a -S -p=instcombine,scalarizer,instcombine < t.ll
; ModuleID = '<stdin>'
source_filename = "<stdin>"

define <3 x float> @main(<3 x float> %arg) {
  %arg.fr = freeze <3 x float> %arg
  %arg.i1 = extractelement <3 x float> %arg.fr, i64 1
  %mul.i1 = fmul float %arg.i1, 0.000000e+00
  %fr = insertelement <3 x float> <float 0.000000e+00, float poison, float 0.000000e+00>, float %mul.i1, i64 1
  ret <3 x float> %fr
}

After #154336 I get:

$ ./opt-b -S -p=instcombine,scalarizer,instcombine < t.ll
; ModuleID = '<stdin>'
source_filename = "<stdin>"

define <3 x float> @main(<3 x float> %arg) {
  %arg.fr = freeze <3 x float> %arg
  %arg.i0 = extractelement <3 x float> %arg.fr, i64 0
  %arg.i1 = extractelement <3 x float> %arg.fr, i64 1
  %arg.i2 = extractelement <3 x float> %arg.fr, i64 2
  %mul.i0 = fmul float %arg.i0, 0.000000e+00
  %mul.i1 = fmul float %arg.i1, 0.000000e+00
  %mul.i2 = fmul float %arg.i2, 0.000000e+00
  %mul.upto0 = insertelement <3 x float> poison, float %mul.i0, i64 0
  %mul.upto1 = insertelement <3 x float> %mul.upto0, float %mul.i1, i64 1
  %mul = insertelement <3 x float> %mul.upto1, float %mul.i2, i64 2
  ret <3 x float> %mul
}

The difference is that after #154336, pushing freeze through both operands of the fmul has the effect of "freezing" <float poison, float 0.0, float poison> to <float 0.0, float 0.0, float 0.0>. Then when the vector fmul is scalarized, we have lost the fact that two of the resulting scalar fmuls are known to be poison and can be removed.