On -O0, i1 strict_fsetcc will be promoted to i32. We can't handle that in TD patterns. This patch fills logic in PPCISelDAGToDAG to handle more cases.
Details
- Reviewers
 steven.zhang nemanjai hfinkel jsji kbarton uweigand - Group Reviewers
 Restricted Project - Commits
 - rG29ae4485950e: [PowerPC] Handle STRICT_FSETCC(S) in more cases
 
Diff Detail
- Repository
 - rG LLVM Github Monorepo
 
Event Timeline
| llvm/lib/Target/PowerPC/PPCISelDAGToDAG.cpp | ||
|---|---|---|
| 4176 | This is wrong for strict mode. You'll need to create a strict version of SELECT_CC here, and this needs to handle the (incoming and outgoing) chain.  | |
| 4199 | This doesn't make sense - the RLWINM instruction does not actually have two outputs. Again, the outgoing chain needs to be processed by the strict SELECT_CC above. The RLWINM (as a pure integer operation) only creates the integer output. It can be merged back with the chain from above using e.g. MERGE_VALUES here.  | |
| 4210 | Same comment as above.  | |
| llvm/lib/Target/PowerPC/PPCISelDAGToDAG.cpp | ||
|---|---|---|
| 4176 | I think here the method name is a little bit confusing.. It doesn't create SELECT_CC, instead, it selects the fcmp* opcode by operand type and predicate, and return a machine node of that. But yes, the chain needs to be handled here since it's the core FP operation we want.  | |
This is wrong for strict mode. You'll need to create a strict version of SELECT_CC here, and this needs to handle the (incoming and outgoing) chain.