[LLVMdev] struct returns

Dan Gohman gohman at apple.com
Wed Sep 16 10:55:58 PDT 2009

On Sep 16, 2009, at 5:58 AM, Kenneth Uildriks wrote:

>> I recently made a major reorganization of the calling-convention
>> lowering code which cleared away one of the major obstacles to
>> doing this within codegen.
>> Dan
> So what was the obstacle, and how was it cleared?

The biggest obstacle is that there used to be two different methods
for lowering call arguments; some of the targets used on and some
used another. There wasn't a good reason for having two, but no one
had taken the time to update all the targets. Now, all targets are
using the same basic set of hooks. And, the hooks are more
straight-forward than the mechanisms they replaced.

>  And how do you see
> the large struct return working in codegen?

One part of the action will be in
lib/CodeGen/SelectionDAG/SelectionDAGBuild.cpp. This is where LLVM IR
is translated into the special-purpose instruction-selection IR, which
is lower-level. Calls are split up into multiple parts which are
eventually lowered into the actual instructions for the calling
sequence. The main areas of attention will be


These functions are responsible for breaking up LLVM IR values into
register-sized pieces and handing them off to target-specific code
through these virtual functions:


(Actually, SelectionDAGLowering::LowerCallTo calls
TargetLowering::LowerCallTo, which calls TargetLowering::LowerCall,
for historical reasons.)

Basically, the task here is to interpose code which will recognize
when an automatic sret is needed, set up a static alloca to hold the
value (see the StaticAllocaMap), and adjust the argument list and
return code accordingly.

For recognizing when an sret is needed, it'll be necessary to know
what the target supports. This is described in the targets'
*CallingConv.td files. Currently the consumer of this information
is the CallingConvLowering code in


This code is currently used from within the target-specific code
inside LowerFormalArguments and friends. However, it could also
be called from the SelectionDAGBuild directly to determine
if there are sufficient registers. It'll need to be extended
some, because it calls llvm_unreachable() when it runs
out of registers, which is the behavior we're trying to avoid
here :-).

If you're not familiar with the SelectionDAG IR, feel free to
ask questions. I recommend using the -view-dag-combine1-dags
option, which provides a visualization of the SelectionDAG for
each basic block immediately after it has been constructed, to
get an idea of what's being built.

> Anything you care to tell me would be welcome.  I will be starting on
> this today or tomorrow.

Ok, let me know if I can answer any questions.


More information about the llvm-dev mailing list