[LLVMdev] Flags/ConditionCode Model is broken

Evan Cheng echeng at apple.com
Sun Mar 22 23:26:13 PDT 2009


On Mar 22, 2009, at 7:53 AM, someguy wrote:

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

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.

Evan

>
> Something which is missing here is that it's not possible (SFAIK) to
> change/add node properties on existing 'standard' nodes. So for
> targets whose 'add' instruction modifies the flags, a custom ADD node
> must be used. One can't use the  'instrinsic' add def-ed in
> TargetSelectionDAG.td. Ideally it should be possible to use these
> existing records, marking them as using or def-ing the flags.
>
> In addition, setcc doesn't gel with this model at all. setcc expects
> an explicit output operand. In order to properly fit in with the
> 'out-of-band' flags model, setcc should NOT have an explicit output,
> but should always be SDNPOutFlag, and set the flags as its result.
> Currently setcc is NOT SDNPOutFlag - this is just confusing and
> broken.
>
> In general, it would be really great if there was a 'unified flag
> theory' ;) If flags are modeled as CPU '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 the flags (even as a
> side-effect) should do so explicitly. In this case, setcc should
> always set a special flags register.
>
> Just my 2c.
> Thoughts?
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev




More information about the llvm-dev mailing list