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

[qcolombet]

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.
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?

2. Where does this contract apply?

For instance, is it at the start of the backend or at ISel (assuming those two definitions are different).

* Implications *

Personally, I consider the backend starts at isel time and that the contract should remain what it is currently: being able to select any valid LLVM IR. I.e., this means we cannot rely on any LLVM IR legalization without changing the contract.

Thoughts?

Thanks,
-Quentin

[mehdi_amini]

Wishful thinking IMO.

Many IR constructs will be rejected by multiple in-tree backends today, because they expect a subset of the possible IR. Either they rely on some pass to “lower” the IR (CGP?), or they expect front-ends to avoid generating unsupported constructs.

[jyknight]

Your definition seems not to be how LLVM currently works -- at least AFAICT. There are a bunch of backend-specific IR passes now -- is it not the case that most backends would fail to work if you disabled those? E.g. AtomicExpandPass, and the various passes added by addPassesToHandleExceptions? Aren't those required?

I'm also not sure why it'd be a useful definition to have. What purpose would be served by requiring that a backend is not allowed to use an IR->IR pass for part of its legalization? Isn't that invisible to the outside world? Why would it matter -- as long as the set of backend-specific IR->IR passes, plus ISel, accomplishes the desired outcome, who cares how the work is split up?

[MatzeB]

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?

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()... So I don't see any "contract" problems here whether we have some IR passes before ISel or not... Obviously you may have a contract inside the backend as to what IR may reach the ISel phase.

- Matthias

[qcolombet]

Hi James,

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.
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?

2. Where does this contract apply?

For instance, is it at the start of the backend or at ISel (assuming those two definitions are different).

• Implications *

Personally, I consider the backend starts at isel time and that the contract should remain what it is currently: being able to select any valid LLVM IR. I.e., this means we cannot rely on any LLVM IR legalization without changing the contract.

Thoughts?

Your definition seems not to be how LLVM currently works – at least AFAICT. There are a bunch of backend-specific IR passes now – is it not the case that most backends would fail to work if you disabled those? E.g. AtomicExpandPass, and the various passes added by addPassesToHandleExceptions? Aren’t those required?

Good question and I don’t know!
That’s why this RFC is useful :).

I’m also not sure why it’d be a useful definition to have.

Is for testing purposes. Basically, I am less interested into what comes into the backend than what comes to the ISel of the backend.

What purpose would be served by requiring that a backend is not allowed to use an IR->IR pass for part of its legalization?

I am not saying the backend could not do that, I am saying that whatever we do, ISel should still support legalization. In other words, having an IR to IR legal is redundant if the contract is ISel should support any valid IR.

Isn’t that invisible to the outside world? Why would it matter – as long as the set of backend-specific IR->IR passes, plus ISel, accomplishes the desired outcome, who cares how the work is split up?

I care :).
I want a clear contract on what ISel will have as input, again for testing purposes.

Thanks,
-Quentin

[qcolombet]

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.

[MARCELLO_MAGGIONI1]

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()... So I don't see any "contract" problems here whether we have some IR passes before ISel or not... Obviously you may have a contract inside the backend as to what IR may reach the ISel phase.

+1

Marcello

[Finkel_Hal_J]

From: "Quentin Colombet via llvm-dev" <llvm-dev@lists.llvm.org>
To: "Matthias Braun" <matze@braunis.de>
Cc: "llvm-dev" <llvm-dev@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

>
>
>>
>> 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

[qcolombet]

From: “Quentin Colombet via llvm-dev” <llvm-dev@lists.llvm.org>
To: “Matthias Braun” <matze@braunis.de>
Cc: “llvm-dev” <llvm-dev@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

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.

[Finkel_Hal_J]

From: "Quentin Colombet" <qcolombet@apple.com>
To: "Hal Finkel" <hfinkel@anl.gov>
Cc: "llvm-dev" <llvm-dev@lists.llvm.org>, "Matthias Braun"
<matze@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

> > From: "Quentin Colombet via llvm-dev" < llvm-dev@lists.llvm.org >
>

> > To: "Matthias Braun" < matze@braunis.de >
>

> > Cc: "llvm-dev" < llvm-dev@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@braunis.de
> > > >
> >
>

> > > wrote:
> >
>

> > > > On Jan 22, 2016, at 2:36 PM, Quentin Colombet via llvm-dev
> > >
> >
>

> > >
> >
>

> > > > 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.

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.

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

[qcolombet]

---

From: “Quentin Colombet” <qcolombet@apple.com>
To: “Hal Finkel” <hfinkel@anl.gov>
Cc: “llvm-dev” <llvm-dev@lists.llvm.org>, “Matthias Braun” <matze@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

[echristo]

From: “Quentin Colombet” <qcolombet@apple.com>
To: “Hal Finkel” <hfinkel@anl.gov>
Cc: “llvm-dev” <llvm-dev@lists.llvm.org>, “Matthias Braun” <matze@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