[LLVMdev] Proposal for new Legalization framework

[Chris Lattner]

On Apr 25, 2013, at 8:58 AM, Dan Gohman <dan433584 at gmail.com> wrote:
> 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.

Sure, I'm happy to explain.  I apologize if I came across overly-strong about this.  This is something that has come up many times before.

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

That's definitely a fair criticism.  In my (often crazy) mind, I'd like to solve a few problems in SelectionDAG that are not just an aspect of the DAG representation.  One specific problem area with SelectionDAG (ignoring the DAG) is that various steps (legalization, isel, etc) want to introduce target specific operations that *require* a specific register class.  The only way to model that in SelectionDAG is by picking an MVT that happens to align with it, and hoping that the right thing happens downstream.

It would be much better if SelectionDAG (and its replacement) could represent register classes directly in its type system.  However, this is a really really bad idea for LLVM IR for hopefully obvious reasons.

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

No, I'm not specifically concerned with number of intrinsics.

> Targets already have large numbers of target-specific intrinsics; would adding a relatively moderate number of new intrinsics really be a problem?

No.

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

I consider this to be one (really important!) example of an invariant that would have to be violated to make this plan happen.  I think that (in order to make this really work) we'd have to add a non-SSA LLVM IR, potentially multiple return results, subregs, etc.  I think it is a really bad idea to make LLVM IR more complicated and worse to work with for the benefit of codegen.

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

Number of intrinsics is not a strong concern for me.

-Chris

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130426/655aa518/attachment.html>