search for: sdnpoptinflag

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

...Style { 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 two instructions...

...; 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 > > _______________________________________________ > LLVM D...

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 other binary inst...

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

...e 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, etc. > Okay...

...nstructions, typically in the case for conditionnal branch, where an instruction which sets the condition codes is followed by a conditionnal branch. Assuming CCFLAGS is defined in my registerInfo.td, and that I am using llvm-2.5 release, it seems several items need to be set in the .td file : 1 - SDNPOptInFlag / SDNPOptOutFlag 2 - Defs = [CCFLAGS] / Uses = [CCFLAGS] 3 - (implicit CCFLAGS) 4 - explicit usage of CCFLAGS As a new comer to LLVM, I am missing the druid's lore to pick up the mixture of right items to have it work. I am asking the question because in our case, I observe that the pre-RA-sc...

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 differentiating ISD::{S...

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