<div dir="ltr"><blockquote class="gmail_quote" style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex; ">
> That's not it at all. These model instructions reading / writing</blockquote><blockquote class="gmail_quote" style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex; ">
> MVT::Flag a value. That just mean from the scheduler's point of view</blockquote><blockquote class="gmail_quote" style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex; ">
> the node that produces a MVT::Flag and the user have to be scheduled</blockquote><blockquote class="gmail_quote" style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex; ">
> together.</blockquote><br>Wow. That's just super confusing.<br><br>So SDNPInFlag/SNDPOutFlag is used only for scheduling?<br><br><blockquote class="gmail_quote" style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex; ">
I think you're misunderstanding ISD::SETCC.</blockquote><div><span class="Apple-style-span" style="border-collapse: collapse;"><br></span></div><div><span class="Apple-style-span" style="border-collapse: collapse;">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.</span></div>
<div><span class="Apple-style-span" style="border-collapse: collapse;"><br></span></div><div><blockquote class="gmail_quote" style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex; ">
That ISD::ADD and other "standard" nodes cannot be extended</blockquote><span class="Apple-style-span" style="border-collapse: collapse;"><blockquote class="gmail_quote" style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex; ">
in target-specific ways is not accidental; these exist to support</blockquote><blockquote class="gmail_quote" style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex; ">
target-independent lowering and optimization.</blockquote></span></div><div><span class="Apple-style-span" style="border-collapse: collapse;"><br></span></div><div><span class="Apple-style-span" style="border-collapse: collapse;">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'.</span></div>
<div><div><br><blockquote class="gmail_quote" style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex; ">
As for Flags, CodeGen is gradually moving to using explicit</blockquote><blockquote class="gmail_quote" style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex; ">
registers to replace Flags in many cases.  This is an ongoing</blockquote><blockquote class="gmail_quote" style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex; ">
project, driven by people contributing things as they need</blockquote><blockquote class="gmail_quote" style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex; ">
them. You are welcome to contribute.</blockquote><div><br></div><div>This seems like a good plan. Anything which makes the model more coherent is a GoodThing. Where is this documented? </div><div><br></div><div>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 ;)</div>
<div><br></div><div>Justin.</div></div></div></div>