[LLVMdev] SetCC tablegen pattern

Villmow, Micah Micah.Villmow at amd.com
Mon Oct 27 10:39:54 PDT 2008


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>


More information about the llvm-dev mailing list