[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 15:34:35 PST 2016


> 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



More information about the llvm-dev mailing list