[LLVMdev] Proposal for new Legalization framework

[Reed Kotler]

I still feel like we are rushing off to design something new that is of 
, at this time, of hypothetical value, when we have more than adequate 
tools to proceed incrementally from where we are at. I would like to see
us finish what we already have and then think about where to go next.

1) Document and clean up tablegen as it applies today to code generation.
2) Move as much as is possible from selection DAG to IR but leave all 
current selection DAG as legacy; using the pass mechanism allow for both 
the old and new to work, leaving it up to the target to chose which one 
they want to use.
3) See what is left that was hard to move.
    a. Add some new functionality to IR to move this last part.
    b. Modify tablegen to work with this new Selection DAGless mechanism
       but leaving for now the legacy to also work. Possibly
       tablegen could be split into two different tools; new and legacy.

I think that we could arrive at this point in less than a year.

Benefits from this approach:
1) Relief to people working now and starting new ports; i.e. clean up 
and documentation of tablegen.
2) No impact on current work.
3) Low risk.
4) Nothing precluding more ambitious future plans and if anything; 
starting those from a more well understood place.

There is nothing to preclude the more ambitious scheme from being worked 
on now but I think that it could proceed in parallel to this.

My 2c.

Reed


On 04/27/2013 02:47 PM, Eric Christopher wrote:
> 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
>