[LLVMdev] Calling-convention lowering proposal
gohman at apple.com
Sun Apr 26 17:54:53 PDT 2009
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
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.
More information about the llvm-dev