<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, Apr 26, 2013 at 2:09 PM, Renato Golin <span dir="ltr"><<a href="mailto:renato.golin@linaro.org" target="_blank">renato.golin@linaro.org</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div>On 26 April 2013 19:49, Tim Northover <span dir="ltr"><<a href="mailto:t.p.northover@gmail.com" target="_blank">t.p.northover@gmail.com</a>></span> wrote:<br>

</div><div class="gmail_extra"><div><div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div>> To me, the expanding of regular IR will achieve nearly the same result as<br>



> building a lower level IR.<br>
<br>
</div>Remember that we basically already have a lower level IR consisting of<br>
basic blocks of MachineInstrs at the moment.To an extent this has<br>
already proven itself capable of modelling targets, and making it a<br>
first-class IR might be a reasonable amount of work (certainly easier<br>
than SelectionDAG).<br></blockquote><div><br></div><div></div></div></div>This is the point I was going to make and I think Tim hit the core of it.</div><div class="gmail_extra"><br></div><div class="gmail_extra">My (week) opinion is that:</div>


<div class="gmail_extra"><br></div><div class="gmail_extra">Adding lowering information to the IR is NOT the same as building another, lower-level IR. It'll open doors to places we don't want to go, like intermixing different levels, allowing for physical registers to be named in IR, changing many optimizations to worry about lower level IR, etc. I see it with the same disgust as I see inline assembly in C code.</div>

</div></blockquote><div><br></div><div>To all, I'm moving on and accepting what appears to be the consensus of the list, for now.</div>
<div><br></div><div>That said, I believe it would be easy to have levels and prohibit mixing. Just have the Verifier pass reject the new intrinsics. A new CodeGenVerifier pass could be added which accepts them, and tools would run the verifier for the kind of input they expect. There'd be no need to change any existing optimizers. No need to even add any new text to LangRef. The new intrinsics would be documented elsewhere.</div>

<div><br></div><div style>Also, there's no proposal here for physical registers or non-SSA registers anything else like that. I think people are making slippery-slope arguments here, but I also think that a change which requires modifying the optimizers would be a point where the slippery-slope could be practically bounded.</div>
<div><br></div><div>Dan</div><div><br></div></div></div></div>