[LLVMdev] struct returns

[Kenneth Uildriks]

I wish to assure you that I have not forgotten this task, nor failed
to start on it, but I cannot give even a rough estimate on when it
will be completed.

It occurs to me that all declarations of a function pointer, and all
bitcasts to a function pointer, could possibly refer to a function
whose signature must be altered by this fix.  Is the function
signature relevant to the SelectionDAG representation of said function
pointers, or can it be safely ignored when lowering loads, stores, and
bitcasts involving such pointers?

Also, I cannot build the test suite: the option "-disable-llvm-optzns"
passed to llvm-gcc produces several warnings (cc1 seems to think every
letter after 'd' is an individual option), and the option "-m32"
passed to llvm-gcc produces an "unknown command line argument" error
from "cc1".  I have been using llvm-gcc extensively to build my own
front-end project, and have not had a problem with it.  I am reluctant
to make further changes to the source without being able to run the
test suite and satisfy myself that I have not broken something.  I am
running version 4.2.1 of llvm-gcc from the 2.5 release... should I
take a later development snapshot of llvm-gcc?

On Wed, Sep 16, 2009 at 12:55 PM, Dan Gohman <gohman at apple.com> wrote:
>
> 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
>
> SelectionDAGISel::LowerArguments
> SelectionDAGLowering::LowerCallTo
> SelectionDAGLowering::visitRet
>
> 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:
>
> TLI.LowerFormalArguments
> TLI.LowerCall
> TLI.LowerReturn
>
> (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
>
> include/llvm/CodeGen/CallingConvLower.h
> lib/CodeGen/SelectionDAG/CallingConvLower.cpp
>
> 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.
>
> Dan
>
>