llvm dev - Jan 2016 - [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.
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

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

— 
Mehdi


> 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
> 
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev

> On Jan 22, 2016, at 5: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.
> 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?

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?

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

Hi James,
> On Jan 22, 2016, at 3:15 PM, James Knight <jyknight at google.com>
wrote:
> 
>> 
>> On Jan 22, 2016, at 5: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.
>> 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20160122/7b43ce8a/attachment.html>

> 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

> On 22 Jan 2016, at 15:17, Matthias Braun via llvm-dev <llvm-dev at
lists.llvm.org> wrote:
> 
> 
>> 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
> 
> - Matthias
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev