similar to: [LLVMdev] Confusion over ISelLowering of setcc

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

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, 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

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

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

Subject: type inference in nodes like setcc Versions: 2.6, 2.7 As for now, inputs of setcc node have to be same as its result, which is in contradiction to definition in TargetSelectionDAG.td. Example: i32reg <- (setgt i16, i16) Logically, this should be correct. However, tablegen considers it incorrect. Why? Note: I'm currently trying to rewrite tablegen to process this correctly.

B. Scott Michel wrote: >B. Scott Michel wrote: > > >>It'd be easy to hack PromoteOp to make a pass to determine all operands' >>promoted value types, take the max, then figure out some way to >>re-promote them to maximal promoted value type. Except that this is a >>non-optimal solution requiring PromoteOp to potentially traverse the >>operand

B. Scott Michel wrote: > It'd be easy to hack PromoteOp to make a pass to determine all operands' > promoted value types, take the max, then figure out some way to > re-promote them to maximal promoted value type. Except that this is a > non-optimal solution requiring PromoteOp to potentially traverse the > operand tree twice. > > Any suggestions or ideas? >

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

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

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

Hi there, I am currently trying to create an LLVM Backend for a RISC architecture and running into problems with setCC and brcond. First a few explanations: The architecture doesn't have a dedicated flag register, but seven 1-bit-wide so called "condition registers", c0-c6, which can be set by e.g. a compare instruction: > cmp ne, c0, r1, 123 It also supports conditional