[PATCH] D26593: [X86][GlobalISel] Add minimal call lowering support to the IRTranslator

[Quentin Colombet via llvm-commits]

Hi,

Replying in that thread as I did not see the subject brought to the dev mailing list.

> On Nov 14, 2016, at 8:01 AM, Zvi Rackover <zvi.rackover at intel.com> wrote:
> 
> zvi added a comment.
> 
> In https://reviews.llvm.org/D26593#593924, @davide wrote:
> 
>> 
> 
> 
> 
> 
>> OK, I apologize if I missed the whole plan. So, is the goal that of growing this prototype into something ready for production?

Yes, but we are moving incrementally here. Basically we start we a fast selector replacement, i.e., code quality may not be great but the compiler runs fast, then we will add more optimizations. Obviously combines and such will be part of the second step. Unlike SDISel, we don’t need them for correctness.

>> I remember there were some aspects that, although valuable, were voluntarily ignored for the prototype timeframe because there wasn't enough time (e.g. reuse of instcombine for the new selector).
>> I'm pretty sure there are others (which I don't have off the top of my head).

TableGen support was one of them. We are working on it right now.

>> Are these aspects being reconsidered now (out of curiosity)?

As for combines, my vision is to do something similar to the Legalizer, i.e., an helper class with all the generic combines and the target picks what it wants from it. How the generic combines are generated is orthogonal, but yeah, I would like a unified DSL (or pattern based) to represent that, that is then proceed by something (TableGen backend most preferably) that generates both the LLVM IR implementation and the MachineIR implementation.

We won’t look into that at first. In particular I believe we need a fairly reasonable support from different targets to derive the right approach.

Thanks for raising those.

Cheers,
-Quentin

> 
> No need to apologize - you should feel free to raise your concerns.
> The questions in your last comment are about GlobalISel in general which I would prefer the core development team (which are also the reviewers) answer them. Perhaps open a thread in llvm-dev?
> 
> 
> Repository:
>  rL LLVM
> 
> https://reviews.llvm.org/D26593
> 
> 
>