[LLVMdev] Calling-convention lowering proposal

[Dan Gohman]

On Apr 25, 2009, at 1:35 PM, Chris Lattner wrote:
>
> Do clients end up lowering the return information before they lower
> the argument information?  If they do, it should be relatively
> straight-forward to support "spilling to the stack" return values that
> can't fit in physregs.  It would be nice to eventually support
> arbitrary return values in the code generator.  Doing this would
> basically just require return lowering to push an extra iPtr argument.

There are details, but yes, PR2660 will be easier to approach
with this patch :-).

>
>
> Looking at the patch, it seems odd that ISD::LIBCALL still exists.  Is
> the "CSE of libcalls" optimization really important in practice?  If
> so, perhaps this should be done as an explicit dag combine
> optimization: if two clumps of flagged together nodes are identical
> and have the same inputs, replace one clump with the other.  This
> would be a nice general solution instead of something specific to  
> calls.

It comes up in test/CodeGen/ARM/cse-libcalls.ll, at least.  However,
that may be due to the particular way SELECT_CC is legalized. I'm
going to re-evaluate this.

>
>
> Unrelated, but it would also be nice to make INLINEASM nodes have
> their own SDNode subclass someday instead of a bunch of magically
> indexed operands.  Similar to Nate's recent shuffle change.

Patches welcome :-).

>
>
> InputArg/OutputArg should probably contain an ArgFlagsTy instead of
> inherit from it.

I think you're right.  I'll make this change.

Thanks,

Dan