[LLVMdev] Proposal for new Legalization framework

Dan Gohman
Thu, 25 Apr 2013 15:58:33 -0000

On Wed, Apr 24, 2013 at 5:26 PM, Chris Lattner <clattner at apple.com>
wrote:

> On Apr 24, 2013, at 5:01 PM, Dan Gohman <dan433584 at gmail.com>
wrote:
> > In the spirit of the (long-term) intent to migrate away from the
> SelectionDAG framework, it is desirable to implement legalization passes as
> discrete passes. Attached is a patch which implements the beginning of a
> new type legalization pass, to help motivate discussion.
>
> This is a great discussion to have.
>
> > Is LLVM IR the right level for this?
>
> IMO, no, definitely not.
>
> > The main alternative approach that's been discussed is to do
FastISel to
> a target-independent opcode set on MachineInstrs, and then do legalization
> and ultimately the last phase off instruction selection proper after that.
> The most obvious advantage of using LLVM IR for legalization is that
it's
> (currently) more developer-friendly. The most obvious advantage of using
> MachineInstrs is that they would make it easier to do low-level
> manipulations. Also, doing legalization on MachineInstrs would mean
> avoiding having LLVM-IR-level optimization passes which lower the IR, which
> has historically been a design goal of LLVM.
>
> I think that you (in the rest of your email) identify a number of specific
> problems with using LLVM IR for legalization.  These are a lot of specific
> issues caused by the fact that LLVM IR is intentionally not trying to model
> machine issues.  I'm sure you *could* try to make this work by
introducing
> a bunch of new intrinsics into LLVM IR which would model the union of the
> selection dag ISD nodes along with the target specific X86ISD nodes.
>  However, at this point, you have only modeled the operations and
haven't
> modeled the proper type system.
>

I don't wish to argue about this, and am fine following your suggestion.
However, I would like to understand your reasons better.

I don't think the type system is really the issue. The only thing
SelectionDAG's type system has which LLVM IR's lacks which is useful
here
is "untyped", and that's a special-purpose thing that we can
probably
handle in other ways.

You and others are right that there could be a fair number of new
intrinsics, especially considering all the X86ISD ones and all the rest. Is
this a significant concern for you? Targets already have large numbers of
target-specific intrinsics; would adding a relatively moderate number of
new intrinsics really be a problem?

There's also the problem of keeping callers and callees consistent, and
it's indeed quite a dickens, but it need not be a show-stopper.

LLVM IR is just not the right level for this.  You seem to think it
is
> better than MachineInstrs because of developer friendliness, but it
isn't
> clear to me that LLVM IR with the additions you're talking about would
> actually be friendly anymore :-)
>

As I see it, people working in codegen are going to have to deal with lots
of codegeny instructions regardless of whether we call them instructions or
intrinsics. Is it really better one way or the other?


> Personally, I think that the right representation for legalization is
> MachineInstrs supplemented with a type system that allows MVTs as well as
> register classes.  If you are seriously interested in pushing forward on
> this, we should probably discuss it in person, or over beer at the next
> social or something.
>

Ok.

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