[LLVMdev] Flags/ConditionCode Model is broken

someguy just.s0m3.guy+llvmdev at gmail.com
Mon Mar 23 01:10:51 PDT 2009


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

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

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?

All in all, it would be great if there were a unified way of modeling
conditional (flags-based) operations, that is useful both during instruction
selection and scheduling. I'm more than happy to help in whatever way I can
to push this amazing tool forward ;)

Justin.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20090323/9c53acc0/attachment.html>


More information about the llvm-dev mailing list