[LLVMdev] Another struct-return question

[Rodney M. Bates]

For this C code:

     typedef struct s2 {
       char s2C1 , s2C2;
     } s2td;

clang generates:

     %struct.s2 = type { i8, i8 }

which I lets llvm decide on the actual layout of this type.

For the return statement in:

     struct s2 fs2 ( char fs2p1 ) {
       struct s2 ls2;
       ls2.s2C1 = 'B';
       ls2.s2C2 = fs2p1;
       return ls2;
     }

I see this IR:

     %struct.s2 = type { i8, i8 }

     define i16 @fs2(i8 signext %fs2p1) #0 {
     entry:
       %retval = alloca %struct.s2, align 1            ; [#uses=2 type=%struct.s2*]
       ...
       %3 = bitcast %struct.s2* %retval to i16*, !dbg !46 ; [#uses=1 type=i16*] [debug line = 25:0]
       %4 = load i16* %3, align 1, !dbg !46            ; [#uses=1 type=i16] [debug line = 25:0]
       ret i16 %4, !dbg !46                            ; [debug line = 25:0]
     }

which returns the struct in a scalar i16.

I have three questions about this.

1)  Larger structs are returned differently, via memcpy.  Do
     these methods of returning struct values show through in
     the ultimately generated machine code?  It seems hard to
     imagine that, of the many different target code generators
     in llvm, there would not be at least some with standardized
     ABIs that differ in such respects.  Does llvm make target-
     dependent transformations for different targets to match
     their ABIs?  Or do I have to do that at the level of generating
     llvm IR?

2)  To correctly return the value using a bitcast, as in the example, the
     front end has to independently and correctly duplicate the layout that
     llvm will produce.  This seems both very fragile and difficult to
     diagnose when it fails.  My front end already does record layout, but
     I had previously decided, after a discussion on this list, that it was
     better to let llvm do it.  Any advice on the best way here?

3)  I am also a little worried about the implications of returning an
     i16, with alignment of 1.  Won't this create trouble somewhere, or
     at least lose some benefit of returning as a scalar?


-- 
Rodney Bates
rodney.m.bates at acm.org