search for: sdnpoutflag

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 (respectively). This seems like an effective model, as CPU-flag modification can be seen as a kind of side-effect in many cases. Something which is missing here is that it's not possible (SFAIK) to change/...

...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 (respectively). This seems like an effective model, as CPU-flag > modification can be seen as a kind of side-effect in many cases. That's not it at all. These model instructions reading / writ...

...cmp and PCCvcmp_o also without this property. In Sparc backend SPcmpicc is also not using it. But X86cmp does for some reason. I'm trying to understand if I need it for my backend or not. It would be also interesting to get some information about other SDNP-* SelectionDAG node properties, e.g. SDNPOutFlag, SDNPInFlag, SDNPOptInFlag and their purpose. -Roman __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

...nt) def NOResSDTIntBinOp : SDTypeProfile<0, 2, [ SDTCisSameAs<0, 1>, SDTCisInt<0> ]>; //define a node using that profile with a OutFlag //property (which is a way to modelise e.g. HW internal CC registers?) def MYcmpicc : SDNode<"MYISD::CMPICC", NOResSDTIntBinOp, [SDNPOutFlag]>; //define the instruction def MYcmp : InstMYArch<(outs), (ins IntRegs:$src1, IntRegs:$src2), "cmp $src1 $src2;", [(MYcmpicc IntRegs:$src1, IntRegs:$src2)]>; Thanks for having a look on this. If the problem lies not in my ....

def : Pat <(A), (B (C))>; can I connect B and C using a flag here? TIA, -Sanjiv

I think so. If you are defining your own SDNode's, you need to specify one as producing a flag, i.e. SDNPOutFlag; the other will be reading a flag, i.e. SDNPInFlag. Evan On Oct 29, 2008, at 2:55 AM, sanjiv gupta wrote: > def : Pat <(A), (B (C))>; > > can I connect B and C using a flag here? > > TIA, > -Sanjiv > _______________________________________________ > LLVM Developer...

On Thu, 2008-10-30 at 08:51 -0700, Evan Cheng wrote: > I think so. If you are defining your own SDNode's, you need to specify > one as producing a flag, i.e. SDNPOutFlag; the other will be reading a > flag, i.e. SDNPInFlag. > > Evan > The problem is that B produces two values: i8, flag. And I would like to connect C using the flag of B and not by i8. > On Oct 29, 2008, at 2:55 AM, sanjiv gupta wrote: > > > def : Pat <(A), (B (C))&g...

...ameDecorationStyle { None, StdCall, - FastCall + FastCall, + FastCC // the normal fastcc calling convention }; Why is FastCC necessary? Can't you just use FastCall? 4. def X86tailcall: SDNode<"X86ISD::TAILCALL", SDT_X86Call, [SDNPHasChain, SDNPOutFlag, SDNPOptInFlag]>; +def X86truetailcall: SDNode<"X86ISD::TRUETAILCALL", SDT_X86Call, + [SDNPHasChain, SDNPOutFlag, SDNPOptInFlag]>; + Please use X86tailcall. It's not currently used so feel free to change its patterns, etc. 5. +// the following t...

...th ;-). > > If someone could correct me and help me found how to correctly > generate > two labels between one instruction, that would be great! :) One way to solve this right now is to use flag value. But that means ISD::LABEL, ISD::{S|U}DIV, ISD::LOAD, ISD::STORE will be marked SDNPOutFlag and SDNPOptInFlag. But that's just yucky. Perhaps we need to add new variants of these nodes and leave the current opcodes as non-faulting. But I am not certain that's a very clean solution either. Evan > > Thanks, > Nicolas > > _________________________________________...

Hi Evan, Evan Cheng wrote: > > One way to solve this right now is to use flag value. But that means > ISD::LABEL, ISD::{S|U}DIV, ISD::LOAD, ISD::STORE will be marked > SDNPOutFlag and SDNPOptInFlag. But that's just yucky. Perhaps we need > to add new variants of these nodes and leave the current opcodes as > non-faulting. But I am not certain that's a very clean solution either. > > I think having variants (1) or differentiating ISD::{S|U}DIV from...

Hi Evan, first off thanks to you and Chris for taking time. On 6 Sep 2007, at 00:57, Evan Cheng wrote: > We'd like to see tail call optimization to be similar to the target > independent lowering of ISD::CALL nodes. These are auto-generated > from ???CallingConv.td files. Some target specific details such as > function address register (ECX in your example) should be coded in

...ofile<0, 2, [ > SDTCisSameAs<0, 1>, SDTCisInt<0> > ]>; > > //define a node using that profile with a OutFlag > //property (which is a way to modelise e.g. HW internal CC registers?) > def MYcmpicc : SDNode<"MYISD::CMPICC", NOResSDTIntBinOp, > [SDNPOutFlag]>; > > > //define the instruction > def MYcmp : InstMYArch<(outs), (ins IntRegs:$src1, IntRegs:$src2), > "cmp $src1 $src2;", > [(MYcmpicc IntRegs:$src1, IntRegs:$src2)]>; > > > Thanks for having a look o...

...fastcc and the x86_fastcall semantics in an older version of my code. I no longer depend on that so it can be removed as you suggest. sorry for the code corpse :) > 4. > def X86tailcall: SDNode<"X86ISD::TAILCALL", SDT_X86Call, > [SDNPHasChain, SDNPOutFlag, SDNPOptInFlag]>; > +def X86truetailcall: SDNode<"X86ISD::TRUETAILCALL", SDT_X86Call, > + [SDNPHasChain, SDNPOutFlag, SDNPOptInFlag]>; > + > > Please use X86tailcall. It's not currently used so feel free to > change its patterns, e...

Hello Per, > The CMPrr instruction is moved down to after the PHI node. My guess is that > the 'dead' in CFR<imp-def,dead> is to blame, but I can't see what I'm doing > differently from MSP430/sparc that makes this not work. Any help GREATLY > appreciated! It seems like no use of CFR after CMP, indeed. How condbranches on your platform look like (patterns, etc.)

On Thu, 5 Oct 2006, Roman Levenstein wrote: >> Check out how the sparc or powerpc backends handle this. They lower >> to a >> select_cc pseudo-op that expands to an if/then/else control flow. > > Thanks! The hint about a pseudo-op was really good. After I realized how > it works, I started the implementation of SELECT_CC using this approach. > Hopefully, I can

On Nov 7, 2007, at 9:07 AM, Nicolas Geoffray wrote: > Hi Evan, > > Evan Cheng wrote: >> >> One way to solve this right now is to use flag value. But that means >> ISD::LABEL, ISD::{S|U}DIV, ISD::LOAD, ISD::STORE will be marked >> SDNPOutFlag and SDNPOptInFlag. But that's just yucky. Perhaps we need >> to add new variants of these nodes and leave the current opcodes as >> non-faulting. But I am not certain that's a very clean solution >> either. >> >> > > I think having variants (1) or diffe...

...n the next row: %reg16388<def> = CMPrr %reg16384, %reg16385, %CFR<imp-def,dead>; IntRegs:%reg16388,16384,16385 SKIPCOND 1, *%CFR<imp-use>* Or doesn't that count? Following are patters for cmp and skipcond: def cmpcc : SDNode<"CSISD::CMP", SDTIntBinOp, [SDNPOutFlag]>; let Defs = [CFR] in { def CMPrr : InstCS<(outs IntRegs:$dst), (ins IntRegs:$b, IntRegs:$c), "cmp $c, $dst", [(set IntRegs:$dst, (cmpcc IntRegs:$b, IntRegs:$c)), (implicit CFR)]>; } let Uses = [CFR], isBranch = 1, isTerminator = 1 in d...

Hi everyone, In order to have exceptions for non-call instructions (such as sdiv, load or stores), I'm modifying codegen so that it generates a BeginLabel and an EndLabel between the "may throwing" instruction. This is what the codegen of an InvokeInst does. However, when generating native code, only BeginLabel is generated, and it is generated after the instruction. I'm not

> On Wed, 4 Oct 2006, Roman Levenstein wrote: > >> You can add the line > >> setOperationAction(ISD::SELECT, MVT::i32, Expand); > >> to the constructor of you TargetLowering class. See the current > >> backend for an example. > > > > I actually tried it first. But then if, I remember correctly, > SELECT > > nodes were expanded into

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