[global-isel] ABI lowering clarifications

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

[global-isel] ABI lowering clarifications

Justin Holewinski-2
[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

_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: [global-isel] ABI lowering clarifications

Jakob Stoklund Olesen-2

On Aug 9, 2013, at 5:43 AM, Justin Holewinski <[hidden email]> 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 <[hidden email]> 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
_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: [global-isel] ABI lowering clarifications

Jakob Stoklund Olesen-2
In reply to this post by Justin Holewinski-2

On Aug 9, 2013, at 5:43 AM, Justin Holewinski <[hidden email]> 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

_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev