[LLVMdev] Flags/ConditionCode Model is broken

[Eli Friedman]

2009/3/23 someguy <just.s0m3.guy+llvmdev at gmail.com>:
>> > 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?

It's not really that confusing... in a sense, the flags don't
represent any register at all, but if you consider the flag operand to
represent all of the fixed physical registers defined by an
instruction, it should be less confusing.  The scheduler
conservatively assumes that any instruction could clobber the physical
registers the flag operand represents, so it puts the instructions
next to each other.

>> 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/brcond
> pair? This seems a little off.

It's because that's the simplest way to transform LLVM IR; branch
instructions take an arbitrary i1, which might not be the output of a
conditional (one common case is that it could be a logical or of two
conditionals).  brcond is roughly equivalent to the LLVM IR br
instruction, and setcc is roughly equivalent to the LLVM IR icmp
instruction.  The DAGCombiner changes the setcc/brcond combination
into a brcc if it's possible and the target wants it.  Note that for
architectures without an arithmetic flag register, like Alpha, the
standard conditional branch sequence looks a lot like a setcc+brcond.

>> 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.
>
> Understood. Surely there should be some way to 'tack on' the flags related
> properties target-independent lowering and target-dependent lowering. It
> should not be necessary for a target-implementor to effectively reimplement
> al these 'standard' nodes in order to add something so 'trivial'.

It's been sort of considered, but the issue is that the cross-platform
code basically can't touch an addition that has an extra flag result
anyway... it would be a large amount of work to track down all the
places that make "bad" assumptions about standard operations, and it
wouldn't be a significant benefit anyway.

>> 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.
>
> This seems like a good plan. Anything which makes the model more coherent is
> a GoodThing. Where is this documented?

Most of the work here is in the x86 backend, although there have been
fixes for some nasty bugs in cross-platform code...

-Eli