Assistance for calling functions taking structs by value

[sgraham]

I have a runtime struct as below that is best passed by value. Because of its size, it's passed by pointer in the Windows x64 calling convention, but the two fields are passed as regular integer register arguments on aarch64 and SysV x64.

Are there any helpers in IR to help me avoid the knowledge of the specifics of the target's calling convention in my front end? (as in gen_call_to_print_str below)

I saw ir_proto_N which seem like they might be related, but I couldn't figure out a way to e.g. define a new struct ir_type representing RuntimeStr.

I also tried using https://github.com/dstogov/ir?tab=readme-ov-file#llvm-interoperability to check clang->IR but clang generates a "fully expanded" proto, i.e. it's already baked the calling convention knowledge into the IR that it generates.

Not a huge problem, but I feel it will get a bit messy when considering the various cases of both passing and returning structs by value, varargs, multiplied by all the targets. (Also, I don't really know all the finer details of all the platforms! 😅)

typedef struct RuntimeStr {
  const uint8_t* data;
  int64_t length;
} RuntimeStr;

void print_str_impl(RuntimeStr str) {
  printf("%.*s\n", (int)str.length, str.data);
}

void gen_call_to_print_str(Operand* op) {
  // SysV x64 and AArch64 pass a RuntimeStr in registers, but win-x64 passes
  // a pointer beyond 8 bytes.
#if !ARCH_ARM64 && !OS_WINDOWS
  ir_ref addr = ir_CONST_ADDR(print_str_impl);
  ir_CALL_1(IR_VOID, addr, load_operand_if_necessary(op));
#else
  ir_ref addr = ir_CONST_ADDR(print_str_impl);
  ir_ref data = ir_LOAD(IR_ADDR, op->ref);
  ir_ref size = ir_LOAD(IR_I64, ir_ADD_OFFSET(op->ref, 8));
  ir_CALL_2(IR_VOID, addr, data, size);
#endif
}

[dstogov]

IR doesn't implement any support for structs and their passing and returning by value.
I didn't need them for PHP JIT (the primary IR user), and I didn't find a good way to fit them into IR design yet.
I would glad to support them, but this is not in my priority list.

I also tried using https://github.com/dstogov/ir?tab=readme-ov-file#llvm-interoperability to check clang->IR but clang generates a "fully expanded" proto, i.e. it's already baked the calling convention knowledge into the IR that it generates.

I adopted MIR c-tests suite for IR and see few tests failures, because of this problem.

./c-tests/lacc/struct-comma-call.c:Unsupported LLVM type: { i64, float }
ir: ir_load_llvm.c:89: llvm2ir_type: Assertion `0' failed.

[sgraham]

Ah OK, thanks for confirming.

I wrote a (very inefficient) C JIT a while back and even just for dealing with the differences on x64 between Win and SysV it got fairly intricate https://github.com/sgraham/dyibicc/blob/main/src/codegen.in.c#L676 .

I will need to think a little more on the best approach then, as I'd like to allow my language to interop with C transparently.

[sgraham]

Understood.

From the interface perspective, there's not a ton of information that IR needs to know, just that the parameter or return is a struct, and then the types/sizes/aligns of the data of the first ~32 bytes of the struct.

That is one thing that QBE does nicely in it's representation (though it doesn't actually support Windows).

When I get to really needing that feature, I will see what I can come up with. 😀

[sgraham]

My current thought is that I will start with a "lowering-away-structs" pass above IR, as I don't have enough knowledge of the internals of IR to try to implement it directly. So the front end will have to realize when

SomeLargeStruct myfunc(SomeLargeStruct arg0)

needs to be called as

SomeLargeStruct* myfunc(SomeLargeStruct* out_ret, SomeLargeStruct* arg0_copied)

and then do a remapping before ir_CALL and an "unmapping" on function entry. This might lose a bit of efficiency, but I think will be more plausible for me to try to implement.

I'm hoping this will look sort of like a layer above ir_builder.h that could eventually be rolled back into it, but I'm not sure about that until I actually write it. Some edge cases might need more special handling e.g. packing struct { int x; float y; } into a single int register.

[sgraham]

This seems to work fine for Win x64 https://github.com/sgraham/luv60/blob/f0999783219277e54291b3c2c9a7ee70a8b32194/src/parse.c#L1926 and was actually simpler than I expected. It didn't really work out as an upstreamable patch to ir_builder, but only because it's written using the type information structures from my front-end, not for any technical reason. So that could be done, some day.

But now that I'm reading for the first time (heh) about the AArch64 PCS, it seems that it will need to dig into lower levels of IR a little bit. I think passing structs would be fine, it looks like they just need to have each field "exploded" out into registers, or alloca+pointer if large.

But in order to return a struct, the caller needs to alloca the return value space, and pass it in XR (X8) which is specifically reserved for that purpose. So I can't just use the shuffling-before-call approach that works on Windows. Ref: https://developer.arm.com/documentation/102374/0102/Procedure-Call-Standard

[sgraham]

Returns of 9-16 bytes are also problematic on aarch64 too, because they'll be in x0+x1, but I don't think there's any way to get the x1 value.

An IR_U128 type might make sense for ARM as the PCS is specified with various 16 byte limits (then split over two registers). But still probably need an instruction (or flag on call) to set x8 for large struct return

[dstogov]

You see, this is not a simple problem. It's possible to make emulation of by-value-struct-passing through lowering. Doing this during parsing looks like an acceptable practical solution. Of course this is not portable and may not cover all the ABI rules.

The right solution should make structures the first class citizens and then take decision during target CPU code matching and emission.