[LLVMdev] Proposal for new Legalization framework

[Eric Christopher]

On Sat, Apr 27, 2013 at 7:28 PM, Evan Cheng <evan.cheng at apple.com> wrote:
>
> On Apr 27, 2013, at 8:10 AM, Chandler Carruth <chandlerc at google.com> wrote:
>
> On Fri, Apr 26, 2013 at 11:33 PM, Dan Gohman <dan433584 at gmail.com> wrote:
>>
>> To all, I'm moving on and accepting what appears to be the consensus of
>> the list, for now.
>
>
> I want to point out something about this direction that hasn't really come
> up, but I think deserves some better discussion. I don't think it should be
> the basis of a decision one way or the other, its more a consequence of the
> decision.
>
> At the IR level, we have some great infrastructure that doesn't exist at the
> MI level:
>
> - The pass management tools.
> - A verifier that can be run before and after any pass to check the basic
> invariants.
> - The ability to serialize and deserialize to/from a human understandable
> (and authorable) form.
>
> I think before we invest in *significantly* more complexity and logic in the
> MI layer of the optimizer, we will need it to have these three things.
> Without them, the work will be considerably harder, and we will continue to
> be unable to do fine grained testing during the development of new features.
> We might not need all of the capabilities we have in the IR, but I think
> we'll need at least those used to orchestrate fine grained testing and
> validation.
>
>
> MI does have a verifier which can be extended if anything is lacking. I'm
> not seeing how improving MI passes is critical for the an instruction
> selector. But perhaps I am missing some important details.
>

Mostly in the testability and ease of working with and modifying. MI
is nice enough, but IR is extraordinarily easy to modify, serialize,
and test incrementally.

> I agree having the ability to serialize and deserialize the IR is an
> important missing feature for MI. We had an intern working on this before
> but it wasn't successful. My vague plan is this area involves instruction
> selecting directly to a "generic" (and configurable) target. But it's by no
> means a concrete proposal.
>

Nod. That's why going towards the IR legalization first, it seemed
like an easy way to use an existing selector and prototype something
quickly to enable legalization on an aspect of llvm that already has a
great set of infrastructure - while keeping the work reasonably
incremental. Also, as has been pointed out it has a lot of downsides
as well. Not the least of which is the ... unpleasantness of call
legalization.

A generic and configurable target could work, I'm not sure how
different that would be from a more lowered/legalized IR, but we
should definitely chat about it after the llvm conference so we can
get your ideas.

Thanks for all of the comments and look forward to discussing this
further with you.

-eric