<div>Hi:</div><div>We are currently building an internal solution based on LLVM/Clang technologies which involves generating LLVM IR based on Bitcode generated by Clang from C codes.</div><div>We have a C function which prototype looks like the following:</div><div><div>typedef struct {</div><div>    int (*allocFunction)(void* x, void* y);</div><div>    void* YY;</div><div>} Type4;</div></div><div><div>int bar (Type1 *x, Type2 *y, Type3 *z, Type4 bar)</div></div><div><br></div><div><br></div><div>When we compile this code uses Clang 6 into x86_64-apple-macos, the generated function in IR has the type:</div><div><br></div><div><div>; Function Attrs: noinline nounwind optnone ssp uwtable</div><div>define i32 @bar(%struct.Type1*, %struct.Type2*, %struct.Type3*,i32 (i8*, i8*)*, i8*)</div></div><div><br></div><div>Which basically split the two members of Type4 into two arguments, strange, but still understandable.</div><div><br></div><div>However when we are compiling this exact same piece of code into thumbv7-none-linux-android , things gets even stranger:</div><div>define i32 @bar(%struct.Type1*, %struct.Type2*, %struct.Type3*,[2 x i32])</div><div><br></div><div>and when caller is using this function, an alloca with type Type4 is bitcasted to [2 x i32]*, loaded and then passed as argument.</div><div><br></div><div>It would be great if someone could tell me how to tell clang from unpacking my arguments and if that's not possible , the correct way to handle this diffrence.</div><div><br></div><div><br></div><div>Zhang</div><div><br></div><div><br></div><div><tincludetail></tincludetail></div><!--<![endif]-->