search for: conditioncod

...'effects', then they should ALWAYS be modeled as such. ALU and setcc operations should (optionally) carry the SDNPOutFlag property. Any 'predicated' or conditional instruction should be 'trivial' to implement, simply by marking the instruction as SDNPInFlag, and specifying a conditioncode parameter. This may require the addition of some kind of condition-code base type to mark conditioncode operands. Alternatively, CPU flags can be modeled using a special flags register (or register class?). In which case, SNDPInFlag/SNDPOutFlag should be killed, and all instructions which modify...

...hen they should > ALWAYS be modeled as such. ALU and setcc operations should > (optionally) carry the SDNPOutFlag property. Any 'predicated' or > conditional instruction should be 'trivial' to implement, simply by > marking the instruction as SDNPInFlag, and specifying a conditioncode > parameter. This may require the addition of some kind of > condition-code base type to mark conditioncode operands. > > Alternatively, CPU flags can be modeled using a special flags register > (or register class?). In which case, SNDPInFlag/SNDPOutFlag should be > killed, and...

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