[LLVMdev] 64bit MRV problem: { float, float, float} -> { double, float }

Duncan Sands baldrick at free.fr
Mon Jan 25 04:35:50 PST 2010

Hi Ralf,

> I do not understand why this behaviour is required. What is the problem
> in having a function receive a single struct-parameter with three floats
> compared to two scalar parameters?
> source-code (C++):
> struct Test3Float { float a, b, c; };
> void test(Test3Float param, Test3Float* result) { ... }

if you compile this with GCC, you will see that it too passes the first two
floats in one double register, and the remaining float in a different register.
The GCC people didn't make this behaviour up, they are following the platform
ABI specification (which you can find floating around on the internet; the name
is something like "System V application binary interface").  In order to conform
to the standard, the object code produced by LLVM also needs to pass the struct
in the same way.  That said, you could imagine that in the bitcode the struct
would be passed as a struct, rather than double+float, and the code generators
would take care of squirting out the appropriate double+float machine code.
Sadly this is not the case: ABI conformance is handled in the front-end.  The
fundamental reason for this is that some ABI's (eg: the x86-64 one) specify
how parameters are passed based on type information that is available in C
but not in LLVM.  For example, a complex number is passed differently to a
struct containing two floats, even though in LLVM a complex number is exactly
the same as a struct containing two floats.  So if the code generators were to
take care of everything, then the entire C type system would somehow have to
be represented in LLVM bitcode, just for this.  Instead the decision was taken
to require front-ends to deal with this kind of issue.  Yes, this sucks - but
no-one came up with a better solution yet.

> bitcode:
> %"struct.Test3Float" = type { float, float, float }
> define void @_Z4test10Test3FloatPS_(double %param.0, float %param.1,
> %"struct.Test3Float"* %result) { ... }



More information about the llvm-dev mailing list