[llvm-commits] PR6059 patch

[Rafael Espindola]

> Well, that's another thing altogether!  If the purpose of your change is to somehow clean up the argument passing in llvm-gcc, then I'm all in favor.  I don't really know how to do that myself, and I don't think I understand the details of what you're proposing.  I do think it would be a bad idea to add a new hook just for ARM AAPCS.

Not totally another issue, it is just the first use case that needs a
more general solution. Another case that can trivially be moved here
is the special handling we have for AAPCS-VFP.

Another benefit: Remember the discussion about using byval? With the
new organization it is easy for the arm backend to find where to split
the structures that are part in register part in memory. With the
previous arrangement that would be hard since the code was not in an
arm specific area.

> The backend had better be able to correctly handle a function like:
>
> x(i32 arg0, i64 arg1, i64 arg2)
>
> The first argument goes in r0; r1 is unused; arg1 goes in register r2 and r3; and arg2 goes on the stack (with 64-bit alignment).  That is exactly what you're looking for in pr6059, right?
>
> This is the general approach of llvm-gcc: translate the arguments to something that will make the backend do the right thing.  I don't understand why that doesn't work in this case.  Am I missing something?

The point is that if the FE doesn't produce a i64, "correctly
handling" the above function can be defined in way that is convenient.
 A silly example of why it is a good idea to lower things early

struct s {double s; int a}
void f(int, struct s);
void g(int a, double b, int c) {
  struct s x = {s, c};
  f(a, x);
}

If llvm-gcc uses a i64 for the struct and the double, the construction
of the temporary x (or at least two i64) will survive until code
generation notices that the i64 will be split. If llvm-gcc is kind
enough to tell llvm that i32 are going to be used, this get simplified
very early.

Cheers,
-- 
Rafael Ávila de Espíndola