[cfe-dev] Redundant byval in C codegen?

[Zhongxing Xu]

Does that mean that if we created a temporary for a struct argument,
'byval' attribute should not be used to avoid an alloca?

2010/1/17 Rafael Espindola <espindola at google.com>:
>> Could somebody explain the rationale behind this behavior? Thanks.
>
> I have no idea why we are unable to remove one of the allocas in the
> caller, but I think I know why we always keep a copy in the caller and
> one in the callee. Take a modified testcase:
>
> ----------------------------------------
> #include <string.h>
> struct s {
>  int a[40];
> };
>
> void g(struct s a);
>
> void f() {
>  struct s a;
>  memset(&a, 0, sizeof(struct s));
>  g(a);
> }
> ------------------------------
>
> This gets compiled to
> ----------------------
> ...
>  %agg.tmp = alloca %struct.s, align 8            ; <%struct.s*> [#uses=2]
>  %agg.tmp2 = bitcast %struct.s* %agg.tmp to i8*  ; <i8*> [#uses=1]
>  call void @llvm.memset.i64(i8* %agg.tmp2, i8 0, i64 160, i32 8)
>  call void @g(%struct.s* byval %agg.tmp) nounwind optsize
>  ret void
> ....
> ---------------------
>
> Ideally we would not have that alloca since the struct is passed by
> value and we now have first class aggregates. The problem is that
> byval is a pointer. This is very good for the callee since it
> correctly represents the fact that the argument is in memory (as
> mandated by the ABI). It is  not so good for the caller that is forced
> to produce an object in memory that will be copied by the code
> generator.
>
> If we were to use first class aggregates we would have a problem is
> the callee that now would not have explicit loads.
>
> One of my crazy ideas I never have time to implement is to change the
> call function to support passing first class aggregates to byval
> arguments. It already does an implicit copy, this would just add
> support for it copying things that are not in memory in the caller.
>
> Cheers,
> --
> Rafael Ávila de Espíndola
>