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

> On Jan 22, 2016, at 3:17 PM, Matthias Braun <matze at braunis.de>
wrote:
> 
> 
>> On Jan 22, 2016, at 2:36 PM, Quentin Colombet via llvm-dev <llvm-dev
at lists.llvm.org> wrote:
>> 
>> Hi,
>> 
>> I would like your opinions on the contract we have between the LLVM IR
and the backends.
>> 
>> 
>> * Context *
>> 
>> Right now, the backends are supposed to be able to perform instruction
selection on any valid LLVM IR.
> What about IR using builtins that the target doesn't support? Is that
invalid IR?
That is a good question.
Right now, ISel will fail on such input, but maybe we don’t want that.
> 
>> Although this is *not* something I want to change for GlobalISel, I
thought I brought that up on the mailing list to discuss the implications.
>> 
>> In particular, in the past, some people mentioned that they wanted to
do (some part of) the legalization on LLVM IR. This may impact the contract we
have between LLVM IR inputs and the backends and I would like to clarify that.
>> 
>> 
>> * Feedback Needed *
>> 
>> 1. In your opinion where does a “backend" start?
>> 
>> For instance, does a backend starts at llc or at ISel?
> 
> In practical terms I'd say the "backend" is all the passes
added by
LLVMTargetMachine::addPassesToEmitFile()/LLVMTargetMachine::addPassesToEmitMC()…
I can buy that definition of backend :).
> So I don't see any "contract" problems here whether we have
some IR passes before ISel or not…
I basically don’t mind having IR passes before ISel or not, the clarification I
am interested in is the contract for ISel.
I want to be able to write tests that make sense for each pass in the GlobalISel
pipeline and for this, we need to agree on a contract.
> Obviously you may have a contract inside the backend as to what IR may
reach the ISel phase.
We need a contract for the generic part and "support any valid LLVM IR
input” for the IRTranslator is hopefully broad enough to supersede any
restriction the target may have. Now, if people want to go with something
narrower, that is fine, I want to make it clear though.

Thanks,
Q.
> 
> - Matthias

----- Original Message ----- 
> From: "Quentin Colombet via llvm-dev" <llvm-dev at
lists.llvm.org>
> To: "Matthias Braun" <matze at braunis.de>
> Cc: "llvm-dev" <llvm-dev at lists.llvm.org>
> Sent: Friday, January 22, 2016 5:34:35 PM
> Subject: Re: [llvm-dev] [GlobalISel][RFC] Contract between LLVM IR
> and the backends for ISel
> > On Jan 22, 2016, at 3:17 PM, Matthias Braun <matze at
braunis.de>
> > wrote:
> >
> >
> >> On Jan 22, 2016, at 2:36 PM, Quentin Colombet via llvm-dev
> >> <llvm-dev at lists.llvm.org> wrote:
> >>
> >> Hi,
> >>
> >> I would like your opinions on the contract we have between the
> >> LLVM IR and the backends.
> >>
> >>
> >> * Context *
> >>
> >> Right now, the backends are supposed to be able to perform
> >> instruction selection on any valid LLVM IR.
> > What about IR using builtins that the target doesn't support? Is
> > that invalid IR?
> That is a good question.
> Right now, ISel will fail on such input, but maybe we don’t want
> that.
> >
> >> Although this is *not* something I want to change for GlobalISel,
> >> I thought I brought that up on the mailing list to discuss the
> >> implications.
> >>
> >> In particular, in the past, some people mentioned that they wanted
> >> to do (some part of) the legalization on LLVM IR. This may impact
> >> the contract we have between LLVM IR inputs and the backends and
> >> I would like to clarify that.
> >>
> >>
> >> * Feedback Needed *
> >>
> >> 1. In your opinion where does a “backend" start?
> >>
> >> For instance, does a backend starts at llc or at ISel?
> >
> > In practical terms I'd say the "backend" is all the
passes added by
> >
LLVMTargetMachine::addPassesToEmitFile()/LLVMTargetMachine::addPassesToEmitMC()…
> I can buy that definition of backend :).
> > So I don't see any "contract" problems here whether we
have some IR
> > passes before ISel or not…
> I basically don’t mind having IR passes before ISel or not, the
> clarification I am interested in is the contract for ISel.
> I want to be able to write tests that make sense for each pass in the
> GlobalISel pipeline and for this, we need to agree on a contract.
> > Obviously you may have a contract inside the backend as to what IR
> > may reach the ISel phase.
> We need a contract for the generic part and "support any valid LLVM
> IR input” for the IRTranslator is hopefully broad enough to
> supersede any restriction the target may have. Now, if people want
> to go with something narrower, that is fine, I want to make it clear
> though.
A backend should be defined to be whatever passes compose it (IR-level passes
included). However, the generic code still needs to be able to handle any input
IR (even if later target-specific code relies on earlier IR-level
target-specific passes).

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.

 -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

> On Jan 22, 2016, at 4:10 PM, Hal Finkel <hfinkel at anl.gov> wrote:
> 
> ----- Original Message ----- 
> 
>> From: "Quentin Colombet via llvm-dev" <llvm-dev at
lists.llvm.org <mailto:llvm-dev at lists.llvm.org>>
>> To: "Matthias Braun" <matze at braunis.de <mailto:matze
at braunis.de>>
>> Cc: "llvm-dev" <llvm-dev at lists.llvm.org
<mailto:llvm-dev at lists.llvm.org>>
>> Sent: Friday, January 22, 2016 5:34:35 PM
>> Subject: Re: [llvm-dev] [GlobalISel][RFC] Contract between LLVM IR
>> and the backends for ISel
> 
>>> On Jan 22, 2016, at 3:17 PM, Matthias Braun <matze at
braunis.de>
>>> wrote:
>>> 
>>> 
>>>> On Jan 22, 2016, at 2:36 PM, Quentin Colombet via llvm-dev
>>>> <llvm-dev at lists.llvm.org> wrote:
>>>> 
>>>> Hi,
>>>> 
>>>> I would like your opinions on the contract we have between the
>>>> LLVM IR and the backends.
>>>> 
>>>> 
>>>> * Context *
>>>> 
>>>> Right now, the backends are supposed to be able to perform
>>>> instruction selection on any valid LLVM IR.
>>> What about IR using builtins that the target doesn't support?
Is
>>> that invalid IR?
> 
>> That is a good question.
>> Right now, ISel will fail on such input, but maybe we don’t want
>> that.
> 
>>> 
>>>> Although this is *not* something I want to change for
GlobalISel,
>>>> I thought I brought that up on the mailing list to discuss the
>>>> implications.
>>>> 
>>>> In particular, in the past, some people mentioned that they
wanted
>>>> to do (some part of) the legalization on LLVM IR. This may
impact
>>>> the contract we have between LLVM IR inputs and the backends
and
>>>> I would like to clarify that.
>>>> 
>>>> 
>>>> * Feedback Needed *
>>>> 
>>>> 1. In your opinion where does a “backend" start?
>>>> 
>>>> For instance, does a backend starts at llc or at ISel?
>>> 
>>> In practical terms I'd say the "backend" is all the
passes added by
>>>
LLVMTargetMachine::addPassesToEmitFile()/LLVMTargetMachine::addPassesToEmitMC()…
> 
>> I can buy that definition of backend :).
> 
>>> So I don't see any "contract" problems here whether
we have some IR
>>> passes before ISel or not…
> 
>> I basically don’t mind having IR passes before ISel or not, the
>> clarification I am interested in is the contract for ISel.
>> I want to be able to write tests that make sense for each pass in the
>> GlobalISel pipeline and for this, we need to agree on a contract.
> 
>>> Obviously you may have a contract inside the backend as to what IR
>>> may reach the ISel phase.
> 
>> We need a contract for the generic part and "support any valid
LLVM
>> IR input” for the IRTranslator is hopefully broad enough to
>> supersede any restriction the target may have. Now, if people want
>> to go with something narrower, that is fine, I want to make it clear
>> though.
> 
> A backend should be defined to be whatever passes compose it (IR-level
passes included). However, the generic code still needs to be able to handle any
input IR (even if later target-specific code relies on earlier IR-level
target-specific passes).
Agreed. That is what I wanted to push and make sure everyone agrees.
The goal here is to be able to define a sort of test suite for backend bring-up.
I.e., I was envisioning having those generic (modulo ABI) tests for the
different generic passes and when someone wants to support GISel for its target,
he starts with that test-suite that should give a coverage ti generate
functional code.
> 
> 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. 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) 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20160122/ddae9307/attachment.html>