[LLVMdev] Proposal for new Legalization framework

Dan Gohman dan433584 at gmail.com
Thu Apr 25 08:00:37 PDT 2013


On Wed, Apr 24, 2013 at 11:33 PM, Owen Anderson <resistor at mac.com> wrote:

> Hi Dan,
>

Hi Owen,


> Others have weighed in on the merits of IR vs MI legalization, I thought
> I'd chip in on a different area:
>
> +    /// Legal roughly means there's a physical register class on the
> target
> +    /// machine for a type, and there's a reasonable set of instructions
> +    /// which operate on registers of this class and interpret their
> contents
> +    /// as instances of the type. For convenience, Legal is also used for
> +    /// types which are not legalized by this pass (vectors, floats, etc.)
> +    Legal,
>
> I don't think this is the right definition of a legal type.  I know that
> that's how SelectionDAG currently defines it, and I think that definition
> is behind a lot of the difficulty in retargeting LLVM to something that
> doesn't look like the intersection of X86 and ARM.
>

Do you have a particular target in mind that we could discuss? Not all
variances from the intersection of x86 and ARM are of the same nature; it's
hard to talk in full generality here.


> I think the correct answer (credit to Chris for this description) is that
> a legal type is one that (more or less) corresponds to a set of physical
> registers, and which the target is capable of loading, storing, and copying
> (possibly also inserting/extracting elements, for vector types).
>

If the target doesn't actually have a copy for a register class which will
be register-allocated, it will just need to pretend it has one at this
level and lower it later somehow, otherwise a lot of other stuff won't work.

I don't see why load and store are special at this level though. Or
insert/extract element?

Dan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130425/ff22942c/attachment.html>


More information about the llvm-dev mailing list