When inverting the compare predicate trySwapVSelectOperands is
incorrectly using the type of the select's cond operand rather
than the type of cond's operands. This means we're treating all
inversions as if they're integer.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
llvm/lib/Target/AArch64/AArch64ISelLowering.cpp | ||
---|---|---|
17628 | Hi @paulwalker-arm, I actually think this is still wrong because I'm pretty sure we should be using the SetCC's input operand type, i.e. ISD::getSetCCInverse(CC, SetCC.getOperand(0).getValueType()) The reason is that the setcc may actually use integer operands, i.e. %p = icmp eq <vscale x 4 x i32> %c, zeroinitializer %fmul = fmul <vscale x 4 x float> %a, %b %sel = select <vscale x 4 x i1> %p, <vscale x 4 x float> %a, <vscale x 4 x float> %fmul In fact, this is not your fault, but I think we're missing some tests for this. I don't see anything in trySwapVSelectOperands that precludes this possibility. |
llvm/lib/Target/AArch64/AArch64ISelLowering.cpp | ||
---|---|---|
17628 | Are yes, not sure what I was thinking. Thanks Dave. |
llvm/lib/Target/AArch64/AArch64ISelLowering.cpp | ||
---|---|---|
17628 | Although I've changed one of the tests to use an integer comparison it seems the code wouldn't break anyway because getSetCCInverse is resilient to incorrectly assuming floating point (but not incorrectly assuming integer, which this patch fixes). This begs the question of why the extra parameter is necessary but that's a story for another day. |
Hi @paulwalker-arm, I actually think this is still wrong because I'm pretty sure we should be using the SetCC's input operand type, i.e.
The reason is that the setcc may actually use integer operands, i.e.
In fact, this is not your fault, but I think we're missing some tests for this. I don't see anything in trySwapVSelectOperands that precludes this possibility.