similar to: [LLVMdev] setcc type inference

what's the semantics for setCC if one of the operands is NULL pointer? %ptr=alloc int seteq int*, %pt, NULL what's the result for the second instruction? How about setne, setlt, setgt, setle, and setge? Thanks! Jianzhong

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

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,

After a hiatus on the CellSPU development, I've got all of the instructions necessary to get the llvm-gcc frontend to build. I've now discovered a new and interesting problem that I'm not sure how to solve cleanly and it's due to the fact that CellSPU has no fixed size condition flags. CellSPU's condition flags depend on the size of what's being compared, i.e., if both

It seems like you should be able to statically evaluate these if you assume that NULL is zero and alloca returns an unsigned nonzero pointer value. > what's the semantics for setCC if one of the operands is NULL pointer? > %ptr=alloc int > seteq int*, %pt, NULL > > what's the result for the second instruction? How about setne, setlt, > setgt, setle, and setge? Thanks!

Hi all, I've spent the day trying to understand setcc/select_cc intricacies, and I thought I should mention that so far as I can tell, the modeling of CPU flags, condition codes and therefore conditional instructions seems pretty broken. On the one hand there are the SDNPInFlag/SDNPOutFlag node properties which allow you to mark an instruction as using or def-ing the CPU flags

On Mar 22, 2009, at 7:53 AM, someguy wrote: > Hi all, > > I've spent the day trying to understand setcc/select_cc intricacies, > and I thought I should mention that so far as I can tell, the modeling > of CPU flags, condition codes and therefore conditional instructions > seems pretty broken. > > On the one hand there are the SDNPInFlag/SDNPOutFlag node properties >

Hi, I'm investigating an issue with the PTX backend I've come across (latest version from the trunk). Not being very familiar with Selection Dags, it's highly likely that I misunderstand some part of the process. I'd appreciate if someone can point me in the right direction. Here's the LLVM IR that is causing problems (I'm aware this code doesn't do anything

On May 24, 2008, at 4:25 PM, Marcel Moolenaar wrote: > On May 24, 2008, at 12:12 PM, Bill Wendling wrote: >> Let us know if you would like extra eyes on the two PPC failures. >> Many >> of us have a lot of experience with C++. :-) Do you know where these >> allocations are? > > I don't mind if people help out, so here's some information: Nice!

On Sep 30, 2010, at 2:13 AM, Heikki Kultala wrote: > Bill Wendling wrote: >> On Sep 29, 2010, at 12:36 AM, Heikki Kultala wrote: >> >>> On 29 Sep 2010, at 06:25, Heikki Kultala wrote: >>> >>>> Our architecture has 1-bit boolean predicate registers. >>>> >>>> I've defined comparison >>>> >>>> def

On Fri, Dec 11, 2009 at 1:49 AM, ether zhhb <etherzhhb at gmail.com> wrote: > hi, > > i have a backend that want to do custom combine on SETCC nodes. > > but some time SETCC was combined into BR_CC before i can visit it to > do my own combine, because DAGCombiner always do its own combine > before custom combine. so, is there anyway to prevent it being > combined

I tried to add a isel pattern [(set I32Regs:$dest, (select (seteq I32Regs:$op1, I32Regs:$op1), I32Regs:$op3, I32Regs:$op4))] for my instruction. I get an error message "Could not infer all types in a pattern!" Above the error message it prints error message line containing the name of my op and (set I32Regs:i32:$dest, (select:i32 (setcc:{i1:i8:i16:i32:i64} I32Regs:i32:$op1,

Hi, I am having some issues with how some of the instructions are being legalized. So this is my intial basic block. The area of concern is the last three instructions. I will pick and choose debug output to keep this small. SelectionDAG has 36 nodes: t0: ch = EntryToken t6: i32,ch = CopyFromReg t0, Register:i32 %vreg507 t2: i32,ch = CopyFromReg t0, Register:i32 %vreg17

Bill Wendling wrote: > On Sep 29, 2010, at 12:36 AM, Heikki Kultala wrote: > >> On 29 Sep 2010, at 06:25, Heikki Kultala wrote: >> >>> Our architecture has 1-bit boolean predicate registers. >>> >>> I've defined comparison >>> >>> def NErrb : InstTCE<(outs I1Regs:$op3), (ins I32Regs:$op1,I32Regs:$op2), "", [(set

hi, i have a backend that want to do custom combine on SETCC nodes. but some time SETCC was combined into BR_CC before i can visit it to do my own combine, because DAGCombiner always do its own combine before custom combine. so, is there anyway to prevent it being combined without changing the logic of DAGCombiner? thank you very much --ether

hi Eli, thanks for reply :) i am currently decompose the BR_CC node to a target SETCC node and a target BRCOND node, but since BR_CC node sometimes is combine from a BRCOND node and SETCC node, so i just wondering if theres any better way :) regards --ether

But isn't kinda silly that we transform to xor and then we transform it back. What is the advantage in doing so? Also, since we do that method, I now have to introduce setcc patterns for i1 values, instead of being able to just use logical pattern operators like not. -Dilan On Fri, Jul 21, 2017 at 11:00 AM Dilan Manatunga <manatunga at gmail.com> wrote: > For some reason I

On Sun, 22 Apr 2007, Christopher Lamb wrote: > I have a back end which has both scalar and vector registers that > alias each other. I'm having a problem generating the ISel from > tablegen that appears only when a vector register class is declared > to contain integer vectors. At that moment tablegen doesn't seem to > be able to infer integer types in patterns that it was

On Apr 23, 2007, at 5:06 PM, Chris Lattner wrote: > On Sun, 22 Apr 2007, Christopher Lamb wrote: >> I have a back end which has both scalar and vector registers that >> alias each other. I'm having a problem generating the ISel from >> tablegen that appears only when a vector register class is declared >> to contain integer vectors. At that moment tablegen

I have a back end which has both scalar and vector registers that alias each other. I'm having a problem generating the ISel from tablegen that appears only when a vector register class is declared to contain integer vectors. At that moment tablegen doesn't seem to be able to infer integer types in patterns that it was able to before, but I'm not clear on why that's the