[LLVMdev] Proposal for new Legalization framework

[reed kotler]

Hi Evan,

To me, the expanding of regular IR will achieve nearly the same result 
as building a lower level IR. I think it will be as good as the 
alternate proposals without any negatives but of course
I can't prove that, it's just an opinion.

The big advantage is that this work can proceed incrementally even today.
A new low level IR and redesign can easily miss the mark; suffering from 
what I like to call premature abstraction. It's really hard to know 
which abstraction will work  until you do a lot of the work and then you 
start to see how well it really works. There is no way to really test any
of this alternate proposal and we will only find out that it's not 
working after a huge amount of effort and time has been expended.

With a small amount of work, Dan already achieved some good success 
using the IR approach. Just think how long it will take for the 
alternate proposal to get that far.

If we move the necessary pieces into the current IR and begin work 
there; there is no impact to people. Pieces they already see as upstream 
are just being moved further upstream.

At some point we should be able to just skip over the current DAG and 
hook up downstream with machine basic blocks and such.

Building an experimental new instruction selector that works from the IR 
(or this extended IR) can proceed in parallel.

Open64, from what I understand, has done just fine by just havin one IR.

So nobody has to ever rewrite their port if they are happy with the 
current Selection DAG though after some time there would be little 
support for it.

I think that anything that is revolutionary should require a much much 
higher burden of proof and vetting than something that has a clear 
evolutionary path.

If the revolutionary path cannot be clearly justified then I think it 
should not be chosen.

Reed



On 04/26/2013 08:43 AM, Evan Cheng wrote:
> Hi Reed,
>
>
> Sent from my iPad
>
> On Apr 25, 2013, at 3:46 PM, Reed Kotler <rkotler at mips.com> wrote:
>
>> On 04/24/2013 07:39 PM, Chris Lattner wrote:
>>> On Apr 24, 2013, at 6:27 PM, Reed Kotler <rkotler at mips.com> wrote:
>>>> I would really push towards doing this in LLVM IR as the next step.
>>> What makes you say that?
>>>
>>>> It's possible that what you are proposing is the right "long term" solution but I think it's not a good evolutionary approach; it's more revolutionary.
>>> Doing this in LLVM IR seems like a major step backwards.  It gets us no closer to the ultimate goal, would add a ton of code, and would make the compiler more complex.
>>>
>>> -Chris
>> I did not really answer you question very succinctly because I ranted about selection DAG and that's not the issue here.
>>
>> So you want to have a machine ir and Dan was proposing to do it regular IR.
>>
>> My main reason for using regular IR is that I think it's more likely to be doable in an incremental way and I don't see how creating another IR will help things.
> I believe we, i.e. the entire llvm community, agree that replacing the instruction selector a big undertaking. I believe it will be the most complex and lengthy one that we would have done. It will take some time to create an alternative to selectiondag. Then it will take a couple of years still to migrate the existing targets over before we can kill off selectiondag.
>
> Given that, we really want one true alternative that will live for a long time. So doing instruction selection in llvm IR doesn't make sense unless we believe it will satisfy all of our goals. It will just a technical debt which will be hard to eliminate if it finds a client.
>
>> You can add to the existing IR things that are needed to make it powerful enough to do what machine IR would do.
>>
>> In the end, machine IR will look just like a subset of the current IR plus some additional things so I don't see how it helps make a new one and now there will be many things that are similar to IR but with slightly different rules, a different C++ class definition, etc.
>>
>> I think that path to a machine IR will be very lengthy unless Apple and Google are willing to throw a lot of high quality resources that way.
> Many people are thinking hard about it. I'm optimistic that some concrete proposals will be presented to the community in the next 2-3 months. In the mean time, I think it's best if the interested parties meet to discuss this in person (sorry I understand this is not possible for some). To me, it's almost impossible to discuss such a broad topic in email threads since it will inevitably splinter into multiple threads.
>
> Evan
>
>>
>> Reed
>>
>>
>> _______________________________________________
>> LLVM Developers mailing list
>> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev