[LLVMdev] Proposal for new Legalization framework

[Dan Gohman]

On Fri, Apr 26, 2013 at 2:09 PM, Renato Golin <renato.golin at linaro.org>wrote:

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

To all, I'm moving on and accepting what appears to be the consensus of the
list, for now.

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.

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.

Dan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130426/f534cb8f/attachment.html>