search for: sdnpinflag

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

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

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

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 Developers mailing list > LLVMdev at cs.uiuc.edu ht...

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))>; > > > > can I connect B and C using a flag...

> > > That's not it at all. These model instructions reading / writing > MVT::Flag a value. That just mean from the scheduler's point of view > the node that produces a MVT::Flag and the user have to be scheduled > together. Wow. That's just super confusing. So SDNPInFlag/SNDPOutFlag is used only for scheduling? I think you're misunderstanding ISD::SETCC. I may well be misunderstanding setcc, but my misunderstanding is due, at least in part, to the lack of clarity in the model. Also, why are conditional branches modeled in the Initial Selection DAG as a setcc...

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

On Nov 4, 2008, at 12:12 AM, Matthijs Kooijman wrote: > Hi Dan, > >> Having tblgen pretend that the MOVE isn't the root seems a bit >> counter-intuitive though. > I didn't really mean making RD the root, but rather telling tablegen > that RD > is the "primary" node, corresponding to the input pattern. This > would allow > the properties of

Hi Dan, > Having tblgen pretend that the MOVE isn't the root seems a bit > counter-intuitive though. I didn't really mean making RD the root, but rather telling tablegen that RD is the "primary" node, corresponding to the input pattern. This would allow the properties of the input rd SDNode be properly transferred to the output RD node instead of the MOVE node. I doubt