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