<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Jun 11, 2020 at 6:03 PM John McCall <<a href="mailto:rjmccall@apple.com" target="_blank">rjmccall@apple.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><u></u>




<div>
<div style="font-family:sans-serif"><div style="white-space:normal">
<p dir="auto">On 4 Jun 2020, at 22:45, James Y Knight wrote:</p>

</div>
<div style="white-space:normal"><blockquote style="border-left:2px solid rgb(119,119,119);color:rgb(119,119,119);margin:0px 0px 5px;padding-left:5px"><p dir="auto">On Thu, Jun 4, 2020 at 5:45 PM John McCall <<a href="mailto:rjmccall@apple.com" target="_blank">rjmccall@apple.com</a>> wrote:</p>
<blockquote style="border-left:2px solid rgb(153,153,153);color:rgb(153,153,153);margin:0px 0px 5px;padding-left:5px"><p dir="auto">These attributes would have to spell out the exact expected treatment by<br>
the backend in essentially every aggregate case, and the frontend would<br>
have to carefully select that treatment, and for many ABIs that would<br>
still require counting registers and so on.</p>
</blockquote><p dir="auto">I don't have all the ABIs memorized, but I don't think it would be the case<br>
that the frontend would need to count registers for any of the ABIs I know<br>
of.</p>
</blockquote></div>
<div style="white-space:normal">

<p dir="auto">Well, worst case, I suppose that either such targets would have to do<br>
something special in the frontend like they do now, or they’d need to<br>
use more fine-grained attributes than maybe the ABI suggests.  We’d need<br>
some of the latter anyway — I think there’s some weird situation on<br>
x86-64 where Clang passes some aggregates in both integer and FP registers<br>
due to an early bug (or possibly an ambiguity in the ABI?).</p>

<p dir="auto">I agree that ABIs in practice lower types in a position-invariant way<br>
and then check if they’ve run out of registers.</p>

<p dir="auto">Obviously the frontend would need to continue handling mandatory-indirect<br>
cases like non-trivial C++ types.  Would the frontend handle other<br>
indirect cases on targets like ARM64 that use indirect parameters instead<br>
of the stack argument area for large aggregates, or would the frontend<br>
just mark the argument as <code style="background-color:rgb(247,247,247);border-radius:3px;margin:0px;padding:0px 0.4em" bgcolor="#F7F7F7">abi(“indirect”)</code> and let it be handled by<br>
the backend?</p>

<p dir="auto"></p></div></div></div></blockquote><div>I think it would be best for the backend to be responsible for all direct vs indirect passing, except mandatory-indirect per language semantics. Attempting to do otherwise has a bunch of edge cases. E.g. the RISCV example I used before: you can create an <i>arbitrarily</i> large aggregate by aligning the inner fields, `struct X { short s; double __attribute__((aligned(4096))) d; };` represented in llvm as `%struct.X = type { i64, [4088 x i8], double, [4088 x i8] }` but which can still be passed in only 1 int and 1 float register, when those are available. Yet, if registers aren't available, you get a 8K struct passed indirectly. If we can figure out how to make that work efficiently, might as well do it for all other ABI-specified indirect arguments, too.</div><div><br></div><div><div>Of course, we do need to make sure that all combinations of value-passing ABI vs kind-of-use gets compiled efficiently -- which isn't the case right now. As I mentioned before, we currently compile unnecessarily inefficient code today even for an "int" passed on the stack which is then used by address. And, while returning a struct by-value can generate reasonable code in llvm now, at least on x86_64 with optimizations, the compile-time is awful. And the unoptimized codegen is similarly awful.</div><div><br></div><div>E.g. compiling the following with "clang -O2 -triple x86_64-linux-gnu" produces entirely reasonable assembly output...after 7 seconds of compile time.</div><div>```<br></div><div>%struct.X = type { i64, i64, [3000 x i8] }<br><br>define dso_local %struct.X @bar1() #0 {<br>entry:<br>  %x = alloca %struct.X, align 8<br>  %a = getelementptr inbounds %struct.X, %struct.X* %x, i32 0, i32 0<br>  store i64 1, i64* %a, align 8<br>  %b = getelementptr inbounds %struct.X, %struct.X* %x, i32 0, i32 1<br>  store i64 2, i64* %b, align 8<br>  %c = getelementptr inbounds %struct.X, %struct.X* %x, i32 0, i32 2, i32 999<br>  store i8 3, i8* %c, align 1<br>  %retval = load %struct.X, %struct.X* %x<br>  ret %struct.X %retval<br>}<br></div><div>```</div><div><br></div><div>So...yeah, figuring out a generic solution for how to spell this and still be efficient, is really a prerequisite to having any scheme of the sort I had in mind be workable. I don't have a proposal to solve this.</div></div><div><br></div><div>Here's an idea I just had (so it's probably bad :) -- maybe we allow the frontend to produce indirect return-value and arguments (like byval and sret), but instead of the decision to use that being based on ABI requirements, just allow the indirect vs direct passing style to be "frontend's choice", for any given parameter of any given call instruction. Whichever is more convenient, in each circumstance -- with no impact on the function signature or ABI. The backend would be able to translate indirect->direct, and direct->indirect when doing ABI lowering, in order to produce the correct ABI, no matter which way the value was presented (whereas today it only translates one direction: direct->indirect). Maybe clang would almost always generate calls with values passed indirectly, just like it always generates allocas to hold local variables today -- leaving it up to mem2reg to also promote to SSA values for a call, where that seems valuable.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div style="font-family:sans-serif"><div style="white-space:normal"><p dir="auto">John.</p>

</div>
<div style="white-space:normal"><blockquote style="border-left:2px solid rgb(119,119,119);color:rgb(119,119,119);margin:0px 0px 5px;padding-left:5px"><p dir="auto">I see this as consisting of two independent pieces:<br>
1. Examining the parameter types, and distilling the important information<br>
about each type, *for a given ABI*, into a blob of ABI-specific data.<br>
2. Actually choosing whether to pass a given parameter in a register, or on<br>
the stack, or split up the parameter into multiple registers, etc.<br>
<br>
Step 1 should be done within Clang. The amount of data generated from this<br>
step, for the ABIs I'm familiar with, is small, and can be derived based<br>
only on the frontend type (not location in parameter list, etc).<br>
Step 2 should be done within LLVM, based on the data passed down in the IR.<br>
This of course does need to count registers, among other things.<br>
<br>
So, taking an example from the RISC-V ABI. Given an argument of type:<br>
  struct X { short s; double d; };<br>
Or, similarly,<br>
  struct X __attribute__((packed)) { struct { short i; } s[1]; double d; };<br>
  struct X { short s; double __attribute__((aligned(256))) d; };<br>
<br>
Clang would need to encode metadata saying that this type may be able to be<br>
passed via "INT+FLOAT" register-passing, having the INT of size 2 at offset<br>
0, and FLOAT of size 8 at offset 8/2/256 respectively, for the 3 types<br>
above. (Or maybe the metadata should store a GEP path, rather than<br>
size+offset?)<br>
<br>
Then, LLVM, seeing an argument with the INT+FLOAT ABI rule, would allocate<br>
it to registers/stack as follows:<br>
1. If you're using hardware float, and FLEN >= 8, and XLEN >= 2, and if<br>
there is at least one floating point and one integer register available,<br>
then: Copy the data at the provided offsets into one floating point<br>
register and one integer register (with bits beyond the integer size<br>
undefined).<br>
2. Otherwise, fallback to common aggregate handling rules:<br>
  a. If size is < XLEN,<br>
    i. and if there's 1 integer register available: Pass the struct (as<br>
laid out in memory) in an integer register.<br>
    ii. otherwise: Pass on stack, with alignment min(stack_alignment,<br>
max(type_alignment, XLEN))<br>
  b. If size < XLEN*2,<br>
    i. and there are 2 registers available: Pass the struct (as laid out in<br>
memory) in two integer registers.<br>
    ii. and there is 1 integer register available: Pass XLEN-sized half the<br>
struct in a register, and the other XLEN-sized half on the stack.<br>
    iii. otherwise: Pass the aggregate on stack, with alignment as before.<br>
  c. Otherwise, "pass by reference" -- make a copy on the stack outside the<br>
parameter-passing area, aligned appropriately for its type and then pass a<br>
pointer to that memory in the usual way for passing a scalar.<br>
(leaving out the varargs rules for simplicity).<br>
<br>
There's a lot of rules there, but the frontend shouldn't need to know about<br>
almost all of it -- the frontend only needs to evaluate whether the struct<br>
type matches the specification for INT+FLOAT (and so on, for the other<br>
categories of special handling), and encode that categorization into the<br>
IR.<br>
<br>
Unfortunately, today, Clang *does* know all those rules I listed above --<br>
and LLVM *also* has to know most of them! This is not a good situation.<br>
<br>
I do actually like this</p>
<blockquote style="border-left:2px solid rgb(153,153,153);color:rgb(153,153,153);margin:0px 0px 5px;padding-left:5px"><p dir="auto">approach in many ways, because it provides a path to a world where the<br>
backend stop permissively compiling everything the frontend throws at it<br>
and instead emits an error if the frontend asks for something that<br>
can’t be done, but it’s not going to make things more abstract.</p>
</blockquote><p dir="auto">It doesn't make things more abstract, no. There's still going to be<br>
ABI-specific code in the frontend. But, it separates the concerns better,<br>
and can make the IR required from a frontend more clearly derived from the<br>
ABI.<br>
<br>
</p>
<blockquote style="border-left:2px solid rgb(153,153,153);color:rgb(153,153,153);margin:0px 0px 5px;padding-left:5px"><p dir="auto">Having worked in this space for years, I am convinced that there are two<br>
meaningful points for ABI lowering: (1) the high-level source-language<br>
information and (2) the low-level register and stack conventions.  (1),<br>
for C interop, is always going to be duplicative of Clang.  You can<br>
introduce an intermediate library and make Clang copy all relevant<br>
information out of its AST into that library’s type system, but<br>
fundamentally “all relevant information” is going to just keep<br>
expanding and expanding, and Clang is still going to have a ton of<br>
target-specific ABI lowering code to do that propagation.</p>
</blockquote><p dir="auto">I definitely think it's infeasible to provide all possibly-relevant<br>
information about the frontend language type to LLVM in a ABI-independent<br>
manner. But, providing ABI-specific metadata makes the problem<br>
feasible, because for any particular ABI, the set of parameters derived<br>
from the frontend type system will be small.</p>
</blockquote></div>
<div style="white-space:normal">
</div>
</div>
</div>

</blockquote></div></div>