[llvm-dev] [GlobalISel][RFC] Contract between LLVM IR and the backends for ISel
Quentin Colombet via llvm-dev
llvm-dev at lists.llvm.org
Fri Jan 22 18:06:38 PST 2016
> On Jan 22, 2016, at 5:56 PM, Hal Finkel <hfinkel at anl.gov> wrote:
>
>
> From: "Quentin Colombet" <qcolombet at apple.com>
> To: "Hal Finkel" <hfinkel at anl.gov>
> Cc: "llvm-dev" <llvm-dev at lists.llvm.org>, "Matthias Braun" <matze at braunis.de>
> Sent: Friday, January 22, 2016 7:40:37 PM
> Subject: Re: [llvm-dev] [GlobalISel][RFC] Contract between LLVM IR and the backends for ISel
>
>
>
>
> Honestly, I think it makes perfect sense to do some amount of type legalization (and scalarization) at the IR level, as an implementation detail of the backend design, but as I understand it, that's a separate design question.
>
> I feel it is sad to have all the legalization available on MI but still replicating some logic in the IR.
> To be clear, I'm against that. If we, for example, do type legalization or scalarization, etc. at the IR level, then we should allow the MI level to depend on that. It is really a question of whether we want to use existing IR-level passes to do cleanup after legalization. Keeping all of that logic at the MI level is also fine, and akin to what we have now. In any case, this is a different discussion, except for the fact that the contract fulfilled by the backend should be viewed as being fulfilled by the entire backend, not independently by the MI layer.
Oh I see what you mean. The contract is still the same from the backend perspective, but not the ISel perspective, I was conflict the two notions.
I can live with that :), that means that whatever test suite for backend bring-up we define, it would have to be adapted.
Thanks for the clarifications!
-Quentin
>
> But yes, you are right, if we want to follow that path that is also possible. That being said, my long-term vision (out of the scope of the prototype for GISel) would be to express legalization transformation in a DSL language (tablegen most likely)
>
> Nice!
>
> -Hal
> and then it would be a matter of writing the proper “backend” to generate the code for MI or LLVM IR.
>
> Anyhow thanks!
> Q.
>
>
> -Hal
>
> Thanks,
> Q.
>
>
> - Matthias
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev <http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev>
>
> --
>
> --
> Hal Finkel
> Assistant Computational Scientist
> Leadership Computing Facility
> Argonne National Laboratory
>
>
>
>
> --
> Hal Finkel
> Assistant Computational Scientist
> Leadership Computing Facility
> Argonne National Laboratory
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160122/70807807/attachment.html>
More information about the llvm-dev
mailing list