Fix a regression introduced in D128865.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
While this fixes a regression in an important benchmark, I think we need to re-think how these BitConverts are specified in a follow-up work, as the current list has been highly inconsistent, even before my changes.
I guess, the list has grown organically from the cases that isel needs supporting. Does anyone know if we should be listing all possible cases of a bitcast for a given width? And always have both SReg/VReg? Or it's fine to have a list like specified currently?
llvm/test/CodeGen/AMDGPU/bitcast-v4i64-v16i16.ll | ||
---|---|---|
30–31 ↗ | (On Diff #443253) | Don't you need just this part and the other stores? Why the control flow? |
llvm/test/CodeGen/AMDGPU/bitcast-v4i64-v16i16.ll | ||
---|---|---|
30–31 ↗ | (On Diff #443253) | Looks the failing pattern is very sensitive to the IR coming to the isel. I couldn't repro this with only one bitcast either. |
llvm/test/CodeGen/AMDGPU/bitcast-v4i64-v16i16.ll | ||
---|---|---|
30–31 ↗ | (On Diff #443253) | Merge with amdgcn.bitcast.ll? I think the trick is to have the value defined in a different block and to not have it sink. You can reduce the block count |
Good tip, thanks! Added a couple of tests in bitcast.ll, and reverted an erroneous edit from the original commit that the tests uncovered.