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

Hal Finkel via llvm-dev llvm-dev at lists.llvm.org
Fri Jan 22 16:10:43 PST 2016


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


More information about the llvm-dev mailing list