search for: selectcc

OK, so in you case, you want DAG.getSExtOrTrunc(SetCC, DL, SelectVT) to tunc the result from i64 to i32 on 64 bits targets, if I understand correctly. 2 questions: - Why not generating a selectcc node directly ? It avoid having to mess up with intermediate values. - Why calling getSetCCResultType(VT) ? VT is not the type of a parameter of setcc, and this looks incorrect to me. 2014-07-05 0:34 GMT-07:00 Matt Arsenault <arsenm2 at gmail.com>: > > On Jul 4, 2014, at 8:18 PM, de...

...:14 PM, deadal nix <deadalnix at gmail.com> wrote: > > > OK, so in you case, you want DAG.getSExtOrTrunc(SetCC, DL, SelectVT) to > tunc the result from i64 to i32 on 64 bits targets, if I understand > correctly. > > > > 2 questions: > > - Why not generating a selectcc node directly ? It avoid having to mess > up with intermediate values. > Well first, that's what it did originally and wasn't what I was changing. > selectcc might not be legal, and I'm not sure why it even exists. I don't > see how it's any harder to match select +...

I am attempting to lower the selectCC instruction to the instruction set of the backend I'm working on and I cannot seem to find a way to correctly implement this instruction. I know how this instruction should get implemented; I just have yet to find a way to do it. I want the select_cc instruction to be lowered into a comparison...

...a that has been confusing for me in general for a while. In many cases, the name of the instruction pattern is the same as the LLVM IR instruction, for example, 'and'. In other cases, it is slightly different. For example the 'select_cc' IR instruction seems to match the rule 'selectcc' in several of the backends. And in some other cases, like extract_vector_elt, there doesn't seem to be an equivalent named rule. I've reread the instruction selection section of the docs several times and this is still not clear to me. Is there a place in the code to look to find the...

On Thu, Sep 11, 2008 at 6:14 PM, Villmow, Micah <Micah.Villmow at amd.com> wrote: > I am attempting to lower the selectCC instruction to the instruction set of > the backend I'm working on and I cannot seem to find a way to correctly > implement this instruction. I know how this instruction should get > implemented; I just have yet to find a way to do it. I want the select_cc > instruction to be lowere...

...v-bounces at cs.uiuc.edu] On Behalf Of Eli Friedman Sent: Thursday, September 11, 2008 8:12 PM To: LLVM Developers Mailing List Subject: Re: [LLVMdev] Selection Condition Codes On Thu, Sep 11, 2008 at 6:14 PM, Villmow, Micah <Micah.Villmow at amd.com> wrote: > I am attempting to lower the selectCC instruction to the instruction set of > the backend I'm working on and I cannot seem to find a way to correctly > implement this instruction. I know how this instruction should get > implemented; I just have yet to find a way to do it. I want the select_cc > instruction to be lowere...

It just occured to me that perhaps what happens is that since the cmp-instruction is initially followed by the pseudo-instruction - which doesn't have Uses = [CFR] - that it's marked dead initially, and never changed back when the SKIPCOND is inserted by the custom emitter? But I feel that this would happen in e.g. MSP430 too then... On Wed, Dec 15, 2010 at 10:14 AM, Anton Korobeynikov

Can someone explain how the condition code is passed from the MBlazeTargetLowering::LowerSELECT_CC to MBlazeTargetLowering::EmitCustomSelect custom inserter? In LowerSELECT_CC the condition code is never accessed (Op.GetOperand(4)) and I don't see how it ends up getting correctly passed to the MBlazeTargetLowering::EmitCustomSelect. > SDValue

I cannot understand what does the paragraph mean. Could anyone please elaborate it? http://llvm.cs.uiuc.edu/ChrisLLVM/docs/CodeGenerator.html#selectiondag_legalize "Instead of using a Legalize pass, we could require that every target-specific selector supports and expands every operator and type even if they are not supported and may require many instructions to implement (in fact, this is

Hi, I'm working on a target which have a variable size for CC (the same size as the arguments). As a result getSetCCResultType, return a variable size. In this commit, at the line DAG.getSExtOrTrunc(SetCC, DL, SelectVT), on my target, you end up generating the Node you are replacing, and so creating a loop in the DAG, which give a whole new meaning to the A in the acronym. Subsequent code

Hello! I'm working on a new back-end and have hit a bit of a snag. I'm working on getting selectcc working and have followed the MSP430 model of emitting a custom CMP and SELECT_CC node and matching that with a pseudo-instruction that has useCustomEmitter=1. However, my output ends up very wrong, despite the Machine code being initially correct: # Machine code for function func: Function Live I...