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 | 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 | 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 | 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.
Don't you need just this part and the other stores? Why the control flow?