[LLVMdev] [global-isel] ABI lowering clarifications

[Justin Holewinski]

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