[LLVMdev] Proposal for new Legalization framework

[Reed Kotler]

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

What would be the plan as far as incrementally achieving this alternate 
implementation?

Why has " avoiding having LLVM-IR-level optimization passes which lower 
the IR,  which has historically been a design goal of LLVM"?

> 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
>
>
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>