[LLVMdev] Flags/ConditionCode Model is broken

[Dan Gohman]

Hello,

I think you're misunderstanding ISD::SETCC.   It really is
supposed to output a normal integer value, not a flags result.
It may help to think of SETCC as being similar to BR_CC and
SELECT_CC.  In each of these operators, an implicit flags
value is implicitly produced and consumed, and not exposed
for use by other operators.  The difference between the three
is what the consumer does.  In SETCC, the consumer reads
the flags value and produces an integer value.  This is
needed to implement C code like "int x = y < z;", for example.

As for Flags, CodeGen is gradually moving to using explicit
registers to replace Flags in many cases.  This is an ongoing
project, driven by people contributing things as they need
them. You are welcome to contribute.

That ISD::ADD and other "standard" nodes cannot be extended
in target-specific ways is not accidental; these exist to support
target-independent lowering and optimization.

Dan

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