llvm dev - Jul 2008 - [LLVMdev] Structs as first class values.

On Wednesday 23 July 2008 12:22, Chris Lattner wrote:
> and both produce this machine code:
>
> _test:
> 	movq	(%rsi), %rax
> 	movsd	(%rdi), %xmm0
> 	ret
Ok, that's good.
> >> right thing.  However, returning a {i64, i64, i64, i64} by value
and
> >> having it automatically be returned "by pointer" is less
interesting,
> >
> > What do you mean by "less interesting?"
>
> There are already other ways to handle this, rather than returning the
> entire aggregate by value.  For example, we compile:
>
> struct foo { double X; long Y, Z; };
> struct foo test(double *P1, long *P2) {
>    struct foo F;
>    F.X = *P1;
>    F.Y = *P2;
>    return F;
> }
>
> into:
>
> 	%struct.foo = type { double, i64, i64 }
> define void @test(%struct.foo* noalias sret  %agg.result, double* %P1,
> i64* %P2) nounwind  {
> entry:
> 	load double* %P1, align 8		; <double>:0 [#uses=1]
> 	load i64* %P2, align 8		; <i64>:1 [#uses=1]
> 	getelementptr %struct.foo* %agg.result, i32 0, i32 0		; <double*>:2
> [#uses=1]
> 	store double %0, double* %2, align 8
> 	getelementptr %struct.foo* %agg.result, i32 0, i32 1		; <i64*>:3
> [#uses=1]
> 	store i64 %1, i64* %3, align 8
> 	ret void
> }
>
> which has no first class aggregates.  When the struct is very large
> (e.g. containing an array) you REALLY REALLY do not want to use first-
> class aggregate return, you want to return explicitly by pointer so
> the memcpy is explicit in the IR.
Ok, I see what you mean.  llvm-gcc does the transformation to the hidden
pointer argument.

I'm still not sure this is good.  If I hand-write LLVM IR that returns a
large
struct by value, the generated code should be correct.  It's not right
now AFAIK.  If you want to make the memcpy explicit, we could do the
l;owering in a separate pass.  That's fine with me, as long as it's
handled by LLVM so it produces correct code.
> >> AFAIK, llvm-gcc/g++ does an *extremely* good job of matching the
> >> X86-64 ABI on mainline.
> >
> > But that's all implemented within llvm-gcc.  LLVM codegen right
now
> > does not implement the ABI correctly.
>
> Getting the ABI right requires the front-end to do target-specific
> work.  Without exposing the entire C (and every other language) type
> through to the code generator, there is no good solution for this.  We
> are working to incrementally improve things though.  Thinking the code
> generator will just magically handle all your ABI issues for you is
> wishful thinking :)
I never said anything about magic.  You don't need "the entire C (and
every
other language) type."  What you need is something that tells the code
generator what ABI to use and possibly what the source language was.
It should be possible to then define how each LLVM IR type maps onto the ABI.

                                                        -Dave

On Jul 23, 2008, at 11:57 AM, David Greene wrote:
> I'm still not sure this is good.  If I hand-write LLVM IR that  
> returns a large
> struct by value, the generated code should be correct.  It's not right
> now AFAIK.  If you want to make the memcpy explicit, we could do the
> l;owering in a separate pass.  That's fine with me, as long as it's
> handled by LLVM so it produces correct code.
David, you're missing something here.  There is a many to one mapping  
of C to LLVM types.  From the LLVM type you can't judge what the input  
type was.  You can't just see that an llvm return type is {double,i64}  
and assign to xmm/gpr.  It works in this case, but not in the general  
case.

For example, in this case:

struct x {
   double x;
   float f;
   int i;
};

struct x foo(float *F, int *I) {
   struct x y;
   y.x = *F;
   y.f = *F;
   y.i = *I;
   return y;
}

llvm-gcc produces:

	ret { double, i64 } %mrv5

to get the right ABI.  There is not enough information in the llvm ir  
to do this without the front-end's help.  Again, there is a many to  
one mapping from C type to LLVM type and not all C types that map onto  
the same llvm type are supposed to be handled the same way.

-Chris

On Jul 23, 2008, at 12:58 PM, Chris Lattner wrote:
> Again, there is a many to one mapping from C type to LLVM type and  
> not all C types that map onto the same llvm type are supposed to be  
> handled the same way.
One concrete example is that some ABIs say that _Complex double is  
returned differently than struct { double r,i; }.

-Chris