[llvm-commits] [llvm] r38506 - in /llvm/trunk: lib/VMCore/Verifier.cpp test/Verifier/byval-1.ll test/Verifier/byval-2.ll test/Verifier/byval-3.ll test/Verifier/byval-4.ll

Chris Lattner clattner at apple.com
Tue Jul 17 08:41:40 PDT 2007


On Jul 17, 2007, at 5:47 AM, Duncan Sands wrote:

>> I think that the C standard defines that structures are always passed
>> by value. On some architectures that is done by coping into  
>> registers.
>> In others it is done by putting a copy on the stack.
>
> Sure, but that doesn't mean that byval has be the same thing as
> "C said to pass by value".  I was proposing byval to more or less mean
> "pass by value if the ABI specifies how to pass such a guy by value".
> The question is how to get C semantics out of this.  My suggestion was
> to have the parameter marked byval *and* do an explicit copy in the  
> IR,
> and let the codegenerators eliminate any unnecessary copies (these  
> occur
> when the ABI supports passing the struct by copy, so the explicit copy
> wasn't needed).

The problem is that the code generator won't be able to eliminate the  
extra copy in any of the interesting cases. :(  You end up with extra  
stack space allocated and an extra memcpy.

>> This is not how the x86_64 ABI works. A copy is generated by the
>> caller, and a pointer is passed *implicitly*. It is computed by
>> "stack_pointer + know_offset". We would have to change the abi to
>> support passing such implicit pointers.
>
> I see, thanks for this information.  However this seems to be more or
> less exactly the scheme I was suggesting:

To be clear, the x86-64 abi requires this in *some cases*.  In other  
cases, the struct is passed in registers, and the scheme it uses for  
which registers is very tricky :)

-Chris



More information about the llvm-commits mailing list