I am attempting to match setcc using tablegen w/ the following patterns: def FEQ : Instruction<(outs GPRF32:$dst), (ins GPRF32:$src0, GPRF32:$src1), "eq $dst, $src0, $src1", [(set GPRF32:$dst, (seteq GPRF32:$src0, GPRF32:$src1))]>; And it is failing stating that the result must be an integer. Is there a way around this other than modifying TargetSelectionDAG.td? Also, why is it assumed that all comparison results are always integers? If I put GPRI32 as my destination register, it complains about register classes not matching...... Micah Villmow Systems Engineer Advanced Technology & Performance Advanced Micro Devices Inc. 4555 Great America Pkwy, Santa Clara, CA. 95054 P: 408-572-6219 F: 408-572-6596 -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20081024/67643599/attachment.html>
That's how ISD::SETCC is specified. If you want to change that for your target, you should custom lower these nodes to target nodes. Then you can specify your own SDNode with your own SDTypeProfile. Evan On Oct 24, 2008, at 4:31 PM, Villmow, Micah wrote:> I am attempting to match setcc using tablegen w/ the following > patterns: > def FEQ : Instruction<(outs GPRF32:$dst), (ins GPRF32:$src0, > GPRF32:$src1), “eq $dst, $src0, $src1”, [(set GPRF32:$dst, (seteq > GPRF32:$src0, GPRF32:$src1))]>; > > And it is failing stating that the result must be an integer. Is > there a way around this other than modifying TargetSelectionDAG.td? > Also, why is it assumed that all comparison results are always > integers? > If I put GPRI32 as my destination register, it complains about > register classes not matching…… > > > > Micah Villmow > Systems Engineer > Advanced Technology & Performance > Advanced Micro Devices Inc. > 4555 Great America Pkwy, > Santa Clara, CA. 95054 > P: 408-572-6219 > F: 408-572-6596 > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20081025/ac309562/attachment.html>
Evan, The one problem with this approach is that the LegalizeDAG is expecting whatever I lower to have the same resulting value as setcc, so I am still stuck using i32's for my results no matter what my initial type is. I've found a way around, by inserting the correct conversion instruction manually, but my backend doesn't require integer only comparison results. Just seems like a waste to have all these conversion instructions(which are fairly expensive) for each non-i32 based comparison. ________________________________ From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Evan Cheng Sent: Saturday, October 25, 2008 4:17 PM To: LLVM Developers Mailing List Subject: Re: [LLVMdev] SetCC tablegen pattern That's how ISD::SETCC is specified. If you want to change that for your target, you should custom lower these nodes to target nodes. Then you can specify your own SDNode with your own SDTypeProfile. Evan On Oct 24, 2008, at 4:31 PM, Villmow, Micah wrote: I am attempting to match setcc using tablegen w/ the following patterns: def FEQ : Instruction<(outs GPRF32:$dst), (ins GPRF32:$src0, GPRF32:$src1), "eq $dst, $src0, $src1", [(set GPRF32:$dst, (seteq GPRF32:$src0, GPRF32:$src1))]>; And it is failing stating that the result must be an integer. Is there a way around this other than modifying TargetSelectionDAG.td? Also, why is it assumed that all comparison results are always integers? If I put GPRI32 as my destination register, it complains about register classes not matching...... Micah Villmow Systems Engineer Advanced Technology & Performance Advanced Micro Devices Inc. 4555 Great America Pkwy, Santa Clara, CA. 95054 P: 408-572-6219 F: 408-572-6596 _______________________________________________ LLVM Developers mailing list LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20081027/542d6930/attachment.html>