similar to: [LLVMdev] Variable length condition code for SETCC and SELECT?

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

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

On Wed, May 20, 2009 at 4:55 PM, Dan Gohman <gohman at apple.com> wrote: > Can you explain why you chose the approach of using a new pass? > I pictured removing LegalizeDAG's type legalization code would > mostly consist of finding all the places that use TLI.getTypeAction > and just deleting code for handling its Expand and Promote. Are you > anticipating something more

On May 20, 2009, at 1:34 PM, Eli Friedman wrote: > On Wed, May 20, 2009 at 1:19 PM, Eli Friedman > <eli.friedman at gmail.com> wrote: > >> Per subject, this patch adding an additional pass to handle vector >> >> operations; the idea is that this allows removing the code from >> >> LegalizeDAG that handles illegal types, which should be a significant

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

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

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

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

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.

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,

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

> >> d) Would it be possible with current implementation of soft-float >> support to map f32/f64 to integer types smaller than i32, e.g. to >> i16? >> I have the impression that it is not necessarily the case, since it >> would require that f64 is split into 4 parts. > > Yes, this should be fine. > >> This question is more about a theoretical

On Wed, May 20, 2009 at 5:26 PM, Eli Friedman <eli.friedman at gmail.com> wrote: > On Wed, May 20, 2009 at 4:55 PM, Dan Gohman <gohman at apple.com> wrote: >> Can you explain why you chose the approach of using a new pass? >> I pictured removing LegalizeDAG's type legalization code would >> mostly consist of finding all the places that use TLI.getTypeAction

On Dec 20, 2006, at 2:06 PM, Roman Levenstein wrote: >> >> This will probably require a slightly more extensive patch to >> legalizer. The current mechanism assumes either 1->1 or 1->2 >> expansion. > > Exactly. This is what I meant with "more chellenging";) It is assumed > at several places that 1->1 or 2->2 expanstions are taking place. A

Hi, In my experiments, I need to disable several linking optimizations. However, bzip2, vortex and eon failed if "-disable-opt" was passed to gccld. I tried the out-of-box llvm and the building process provided by llvm-test. The same problem was observed, when I specified EXTRA_LINKTIME_OPT_FLAGS = -disable-opt on Makefile.program and simplied typed "make" under

Hi All, There's a new snapshot of llvmgcc4 available here: http://nondot.org/sabre/2006-05-08-llvm-gcc-4.tar.gz This release includes the various portability fixes contributed on llvmdev, includes fixes to build with mainline CVS (and, thus, *requires* mainline CVS), and includes various other bug fixes. If you're interested, please try it out. Thanks, -Chris --