[LLVMdev] Proposal for new Legalization framework

[Owen Anderson]

On Apr 25, 2013, at 8:00 AM, Dan Gohman <dan433584 at gmail.com> wrote:

> 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 have a target for which v4i8 is legal. I can load it, store it, copy it, insert/extract elements, shuffle it.  But I can't add it, subtract it, multiply it, etc.  It can also load, store, and copy v16f32, but again can't operate on it.

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

I'm open to suggestions on this, but the point was to preserve some functionality for type legalization, rather than going back to the old-style of having only a combined type+op legalizer.  The concept was to prune back the functionality of type legalization to only dispensing with types for which the really is not even minimal hardware support.

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