llvm dev - Aug 2013 - [LLVMdev] [global-isel] ABI lowering clarifications

[snip]
> The ABI boundary lowering requires types to be broken down further into
> 'legal types' that can be mapped to registers. The secondary
breakdown is
> currently handled by TargetLowering::LowerCallTo() calling
> getRegisterType() and getNumRegisters(). Most ABIs are defined in terms
> of C types, not LLVM IR types, so there is a close connection between the C
> frontend and the ABI lowering code in the instruction selector. It would be
> a good idea to have the ABI lowering code work independently of the type
> system used during instruction selection. This is made possible by having
> ABI lowering be part of the LLVM IR to MI translation process.
>
Between virtual registers being typed with EVTs instead of register classes
and the greater flexibility in what is a "legal" type, the ABI
lowering
should become significantly easier for weird targets.  Will
LowerFormalArguments and friends still only see legal types, or will they
see the raw LLVM IR or unlegalized EVT types?

[snip]

Legalization
>
> SelectionDAG's concept of legal types isn't clearly defined. It
seems to
> be a bit random which operations must be supported before a type can be
> considered legal. We'll define legal types precisely:
>
> A type is considered legal if it can be loaded into and stored from an
> allocatable register class. (And all allocatable register classes must
> support copy instructions.)
>
> Does this definition require cross-class copies to be legal?  If I have an
i8 register class that only supports load/store, it seems like some way to
copy it to a larger register to perform other operations would be needed.
 Or is it sufficient that the register class only support storing to the
stack so the value can be ext-loaded to a larger register?

> We don't require other supported operations than load and store for a
type
> to be legal, and all types that can be loaded and stored are legal. This
> means that most targets will have a much larger set of legal types than
> they do today. Also note that we don't require targets to designate a
> register class to use for each legal type; in fact, TableGen can compute
> the legal type set automatically. Register classes can be inferred from the
> selected instructions,MachineRegisterInfo::recomputeRegClass() already
> knows how to do that.
>
[snip]

-- 

Thanks,

Justin Holewinski
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20130809/5bdd2a37/attachment.html>

On Aug 9, 2013, at 5:43 AM, Justin Holewinski <justin.holewinski at
gmail.com> wrote:
>> The ABI boundary lowering requires types to be broken down further into
'legal types' that can be mapped to registers. The secondary breakdown
is currently handled by TargetLowering::LowerCallTo() calling getRegisterType()
and getNumRegisters(). Most ABIs are defined in terms of C types, not LLVM IR
types, so there is a close connection between the C frontend and the ABI
lowering code in the instruction selector. It would be a good idea to have the
ABI lowering code work independently of the type system used during instruction
selection. This is made possible by having ABI lowering be part of the LLVM IR
to MI translation process.
>> 
> Between virtual registers being typed with EVTs instead of register classes
and the greater flexibility in what is a "legal" type, the ABI
lowering should become significantly easier for weird targets.  Will
LowerFormalArguments and friends still only see legal types, or will they see
the raw LLVM IR or unlegalized EVT types?
I would like the ABI lowering to be isolated from the rest of the instruction
selector as much as possible. I don’t think it should use the instruction
selector’s notion of what is a legal type. I is not completely clear how this
should work, we do need some way of breaking down weird types into chunks the
target ABI code understands.

As I see it, types picked by the frontend to match ABI requirements should be
passed directly to the target ABI code. Weird types created by inter-procedural
optimizations are less critical to get right, but they must be lowered into
something.


On Aug 9, 2013, at 2:16 AM, David Chisnall <David.Chisnall at
cl.cam.ac.uk> wrote:
> There is a lot of black magic required for ABI support.  I can read the
SysV ABI supplement for a given architecture and understand how, from my source
language, types should be represented and where function arguments should go. 
There is then almost no documentation on how this maps to the IR, so the only
way when writing a new front end for an existing back end is to see what clang
generates.  The 'clean' design of the IR here is not very clean, as the
IR contains something that is neither what the back end nor the front end wants
and has a non-obvious mapping to either.
I completely agree that the way ABIs are mapped to IR is both dodgy and
undocumented. I just did the SPARCv9 ABI, and it required some strange
applications of the ‘inreg’ attribute that I am not proud of.

However, while this problem needs to be addressed in the future, I think it is
outside the scope of the global isel proposal. I don’t want to mess with LLVM IR
in this context.

Looking forward to when we do address the ABI problem, I think it is important
to handle ABI lowering as early as possible in the MI builder pass. That means
we’ll only have to smuggle ABI semantics through one IR, not two. I also think
we should aim to decouple ABI lowering from the rest of the instruction selector
as much as possible. In particular, I don’t want it to be coupled to the notion
of legal types.

Thanks,
/jakob

On Aug 9, 2013, at 5:43 AM, Justin Holewinski <justin.holewinski at
gmail.com> wrote:
>> Legalization
>> 
>> SelectionDAG's concept of legal types isn't clearly defined. It
seems to be a bit random which operations must be supported before a type can be
considered legal. We'll define legal types precisely:
>> 
>> A type is considered legal if it can be loaded into and stored from an
allocatable register class. (And all allocatable register classes must support
copy instructions.)
>> 
> Does this definition require cross-class copies to be legal?  If I have an
i8 register class that only supports load/store, it seems like some way to copy
it to a larger register to perform other operations would be needed.  Or is it
sufficient that the register class only support storing to the stack so the
value can be ext-loaded to a larger register?
This is where the iterative legalization comes in. The legalizer would initially
widen an i8 operation by using anyext/trunc operations which may not be legal.
These operations may combine with loads and stores to form extload/truncstore,
or they may be legalized some other way.

I imagine that anyext/trunc operations would also be pushed around the CFG, like
the i64 type split in the second example in the proposal.

Thanks,
/jakob