Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
llvm/test/CodeGen/WebAssembly/fshl.ll | ||
---|---|---|
5 | Could do but why? That is definitely not the prevailing style in test/CodeGen/WebAssembly/. |
Do we guarantee that the rotate amount is not undef? (Can we assert that?)
The expansion may fail if the rotate amount is 'undef':
https://alive2.llvm.org/ce/z/tqjuC7
llvm/test/CodeGen/WebAssembly/fshl.ll | ||
---|---|---|
5 | This should be fine. Specifying the target in the IR is the default. |
Can we pre-commit the test before this patch with a FIXME note? This is currently miscompiling?
Undef is a legal rotate amount (because we spec rotate to be modulo the bitwidth, unlike normal shifts, where it is poison). However, I don't think it makes sense to consider undef-related issues at the SDAG layer at this point in time. They are much less likely to cause practical miscompiles here, and it's much harder to be undef-correct in SDAG (because expansion and legalization will often introduce multiple uses of the values, with the issues that may entail, as in this case). Being pedantic about this would need a lot of FREEZE.
Yes, I agree that we don't want to take undef in codegen too seriously. We may want to add that fold for safety though because it seems to survive on most targets here.
And I see now that we are currently crashing on this example (on all targets?), so we need to get this fixed ASAP.
LGTM.
llvm/test/CodeGen/WebAssembly/fshl.ll | ||
---|---|---|
5 | Yeah - don't worry, its just I'm so used to it I think it looks tidier these days.... </OCD> |
llvm/lib/CodeGen/SelectionDAG/TargetLowering.cpp | ||
---|---|---|
6287 | This can't be right - both shifts are HsOpc. We need another test with a variable shift amount to make sure this is correct? |
llvm/lib/CodeGen/SelectionDAG/TargetLowering.cpp | ||
---|---|---|
6287 | It's correct. We want to shift by 1..32, so we do a shift by 1 and then a shift by 0..31. |
llvm/lib/CodeGen/SelectionDAG/TargetLowering.cpp | ||
---|---|---|
6287 | Oops, disregard. Too early in the AM. :) |
This can't be right - both shifts are HsOpc. We need another test with a variable shift amount to make sure this is correct?