[llvm-dev] [GlobalISel][RFC] Contract between LLVM IR and the backends for ISel

Eric Christopher via llvm-dev llvm-dev at lists.llvm.org
Sat Jan 23 11:36:01 PST 2016


On Fri, Jan 22, 2016 at 6:06 PM Quentin Colombet via llvm-dev <
llvm-dev at lists.llvm.org> wrote:

> 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.
>
>
FWIW I share Hal's perspective here. :)

-eric


> 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
> 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
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160123/dfb00a88/attachment.html>


More information about the llvm-dev mailing list