[cfe-dev] Clang and packing/unmacking struts uses as arguments/return values

[Renato Golin]

On 14 February 2014 01:12, David Mirabito <david.mirabito at gmail.com> wrote:
> Which is defined to return { i64, i32 }. I suspect this is because clang
> knows the ABI of my host PC and bakes the calling convention into the IR
> (x86_64-apple-darwin11.4.2). I know enough not to expect to be able to use
> the same .bc on different arches for reasons such as this, at least :)

Yup.



> Because two struct fields are merged, it's not trivial to get the one I'm
> interested in. Even if I do emit the required masks and shifts, what if it
> all changes tomorrow when I want this to work after recompiling everything
> for say, 32b Linux, or ARM with a different calling convention?

You'd have to re-compile the whole thing to a different arch. This is
a know issue and have somewhat been designed that way.

The complexity of implementing all that in the back-ends would be too
huge (at least a huge change, now), to do so effectively. Maybe with
some refactoring going on the selection dag, etc we might get that
streamlined, but I wouldn't hold my breath.


> Is there a way I can have Clang simply use {i32, i32, i32} for that struct
> in a way that GEP/ExtractValue with indices 0, 1, 2 reliably works as
> expected?

Nope. You should talk to the NaCl guys, they have the same problem,
and AFAIK, they solved by having several architecture-specific bitcode
files hanging around.


> Alternatively, could I cast between {i64, i32} and {i32, i32, i32} in a
> reliable way, would that be safe?

You'd have to do that on every function call, so you'd have to track
all PCS-specific lowering on all modules that might interact with that
(or other) functions.

cheers,
--renato