The ARM EABI (AAPCS) defines:
- i64 values are 8-bytes aligned
- "The alignment of an aggregate shall be the alignment of its
most-aligned component."
So,
struct ss {
int x;
int y;
};
void f(int a, struct ss b);
r0 <- a
r1-r2 <- b
void g(int a, long long b);
r0 <- a
r2-r3 <- b
The problem is: llvm-gcc generates the same bytecode for both functions:
declare void @f(i32, i64)
declare void @g(i32, i64)
I can't differ an i64 argument from a struct argument.
Lauro
This is a known deficiency of llvm which we haven't had time to deal with. At llvm level, function arguments are lowered to integer types so some of these type information are lost.
I think adding a short term workaround is possible until we fix this "the right way". It involves adding the alignment information to ParameterAttributes. This will involve llvm language level and llvm-gcc changes.
Evan
Oops. You can fix this by changing llvm-gcc: gcc/llvm-abi.h
Grep for instances of Int64Ty there. I can help answer any q's you might have.
-Chris
I think, we must move function arguments lowering from frontend to
LLVM core. This lowering is generating machine dependent bytecode. See
http://llvm.org/bugs/show_bug.cgi?id=1230
Lauro
This is a design decision to not allow passing aggregates by value. Chris has already started working on some major changes to make llvm flexible enough to represent any calling conventions.
Chris was right though. You can probably fix this particular bug in the frontend by not splitting i64 into a pair of i32's.
Evan
I think, we must move function arguments lowering from frontend to
LLVM core. This lowering is generating machine dependent bytecode. See
1230 – llvm-gcc should not lower calling convs in front-end
I agree. There are two pieces to this as I see it:
1. Make calling conventions easier to nail down. I just completed as
series of changes that allows basic calling conventions to be described
in the .td file for targets. I've converted the X86/X86-64 backends
over so far, I'll do PPC and others will do darwin/ARM in time. Here
is the X86 calling conv description:
http://llvm.org/cvsweb/cvsweb.cgi/llvm/lib/Target/X86/X86CallingConv.td?rev=HEAD&content-type=text/x-cvsweb-markup
I will document this when I have time.
2. We need to stop llvm-gcc from lowering aggregates to scalar values in
the front-end. To do this, we need some thoughtful extensions to LLVM.
This is nontrivial, but important. I don't have immediate plans to do
this, but it's on my mid-range-term todo list. Switching targets over
to use #1 is a prerequisite.
-Chris