[LLVMdev] [global-isel] ABI lowering clarifications

[Jakob Stoklund Olesen]

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