Because of D128669, CPY is being used to zero active lanes even in the case of -0.0f. This patch checks for floating point positive zero. That way SVEDup0 won't match -0.0f.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
I'm not sure how to test this. Also how do I reference the issue I created on Github: https://github.com/llvm/llvm-project/issues/57428?
llvm/lib/Target/AArch64/AArch64ISelDAGToDAG.cpp | ||
---|---|---|
185–186 | Does it make sense to check for isNegative here also? |
Change seems reasonable.
Does https://github.com/llvm/llvm-project/blob/04ae35e592c1e7e99bb3894420b6ff2117ace78a/llvm/lib/Target/AArch64/AArch64ISelLowering.cpp#L2698 have the same issue?
We need regression tests.
Also how do I reference the issue I created on Github
To refer to the issue, just put "Fixes https://github.com/llvm/llvm-project/issues/57428" in the commit message. GitHub will cross-link that automatically.
I'm not sure how to test this.
Backend regression tests generally go into llvm/test/CodeGen/AArch64. You can probably just add a few lines to the existing test llvm/test/CodeGen/AArch64/sve-vselect-imm.ll to cover this case.
llvm/lib/Target/AArch64/AArch64ISelDAGToDAG.cpp | ||
---|---|---|
187 | sorry, I have a question: can we match the -0.0 if the option -ffast-math is added in command ? |
llvm/lib/Target/AArch64/AArch64ISelDAGToDAG.cpp | ||
---|---|---|
187 | That feels a little dangerous to me. I think such a canonicalisation would be better done at the DAG or perhaps even the IR level. For instruction selection it seems safer to be explicit. |
llvm/lib/Target/AArch64/AArch64ISelDAGToDAG.cpp | ||
---|---|---|
187 | Thanks for your information. |
Does it make sense to check for isNegative here also?