<div dir="ltr">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 class="gmail_extra"><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 class="im">> 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>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" style>My (week) opinion is that:</div>
<div class="gmail_extra" style><br></div><div class="gmail_extra" style>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 class="gmail_extra" style><br></div><div class="gmail_extra" style>MachineInstrs is a lower level description that is clearly separated from the LLVM IR and has been converted from it for a long time. As Chris said, a stable high-level IR is very important for front-end and optimization developers, but back-end developers need to tweak it to make it work on their architectures. My conclusion is that we might need to formalize a low level IR, based on MIs, and allow it a very loose leash.</div>
<div class="gmail_extra"><br></div><div class="gmail_extra" style>Why formalize if we already have it working, you ask? I think that even a feeble formalization will improve how code is shared among different back-ends. It'll also be an easy route for a new legalization framework without having to deprecate much code, and without having to leave too much old code dangling on less active back-ends. Each step of stronger formalization can be taken on its own time, implementing on most back-ends, iteratively.</div>
<div class="gmail_extra" style><br></div><div class="gmail_extra" style>As Evan said, whatever we do, this move will take years to complete, much like MC. So, we better plan on something that will be stable throughout the years, rather than try for something quick and drastic, and have hundreds of new bugs dangling for years with no good current solution.</div>
<div class="gmail_extra" style><br></div><div class="gmail_extra" style>My tuppence.</div><div class="gmail_extra" style><br></div><div class="gmail_extra" style>cheers,</div><div class="gmail_extra" style>--renato</div></div>