[LLVMdev] Proposal for new Legalization framework

Evan Cheng
Sat, 27 Apr 2013 18:28:49 -0000

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.

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.

Evan

>
> Of course, adding these to MI would be of great benefit to any number of
other aspects of LLVM's development. I am *not* arguing we should eschew MI
because it lacks these things. I just want people to understand that part of the
cost of deciding that MI is the right layer for this is needing to invest in
these pieces of the MI layer.
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20130427/10c9bac4/attachment.html>