[LLVMdev] Proposal for new Legalization framework

[Renato Golin]

On 26 April 2013 19:49, Tim Northover <t.p.northover at gmail.com> wrote:

> > To me, the expanding of regular IR will achieve nearly the same result as
> > building a lower level IR.
>
> Remember that we basically already have a lower level IR consisting of
> basic blocks of MachineInstrs at the moment.To an extent this has
> already proven itself capable of modelling targets, and making it a
> first-class IR might be a reasonable amount of work (certainly easier
> than SelectionDAG).
>

This is the point I was going to make and I think Tim hit the core of it.

My (week) opinion is that:

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.

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.

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.

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.

My tuppence.

cheers,
--renato
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130426/f64b0a63/attachment.html>