rjmccall added a comment. In D108643#3027473 <https://reviews.llvm.org/D108643#3027473>, @erichkeane wrote:
> In D108643#3026550 <https://reviews.llvm.org/D108643#3026550>, @rjmccall > wrote: > >> I think it would be better to provide a generic ABI specification that is >> designed to "lower" `_BitInt` types into more basic concepts that ABIs >> typically already have rules for. It would be appropriate to note at the >> top that this is only a generic specification and that the rules for any >> particular platform should be codified in a platform-specific ABI. But we >> should make that easy so that platform owners who don't have strong opinions >> about the ABI can just say "as described in version 1.4 of the generic ABI >> at https://clang.llvm.org/..."; >> >> Now, that is all independent of what we actually decide the ABI should be. >> But I do think that if we're going to make this available on all targets, we >> should strongly consider doing a "legalizing" lowering in the frontend: at >> ABI-exposed points (call arguments/parameters and memory accesses), >> `_BitInt` types should be translated into types that a naive backend can be >> trusted to handle in a way that matches the documented ABI. Individual >> targets can then opt in to using the natural lowerings if they promise to >> match the ABI, but that becomes a decision that they make to enable better >> optimization and code generation, not something that's necessary for >> correctness. > > Don't we already have that? We work the same way a 'bool' does, that is, we > zero/sign extend for parameters and return values? The backends then > reliably up-scale these to the power-of-two/multiple-of-pointer. There's two levels of a "legalizing" lowering. On the specification level, we'd be formally saying that the ABI matches the ABI of some other C construct. For example, we might say that a `signed _BitInt(14)` argument is treated exactly as if the argument type was instead `signed short` (with whatever restriction we do or do not impose on the range). This is very nice on this level because, first, it's a rule that works generically for all targets without needing to care about the details of how arguments are assigned to registers or stack slots or whatever; and second, it means you're never adding new cases to the ABI that e.g. libffi would need to care about; and third, you can reliably match the ABI with manually-lowered C code from a compiler that doesn't even support `_BitInt`s. On the implementation level, we'd have to actually emit IR which will turn into code which matches that ABI. I think you are right that small integers already reliably work that way in LLVM, so that if you pass an `i11 sext` it'll get sign-extended to some width — what width exactly, I don't know, but probably the same width that `i16 sext` would be. Larger integers, I'm not sure. A legalizing lowering of big `_BitInt` argument would presumably say either that it's exactly the same as a struct containing all the chunks or that it's exactly the same as a series of arguments for each of the chunks. Those are two very different rules! Most ABIs won't "straddle" a single argument between registers and the stack, so e.g. if you'd need two registers and you only have one left then you exhaust the registers and go fully on the stack; but obviously you can get straddling if the lowering expands the sequence. Similarly, some ABIs will go indirect if the struct gets big enough, but you won't get that if the lowering expands. But on the other hand, if the rule is really that it's like a struct, well, some ABIs don't pass small structs in registers. Anyway, my point is that what exactly LLVM targets do if you give them an `i117` might not match either of these possibilities reliably across targets. In any case, since we currently have to count registers in the frontend for the register-passing ABIs, we'll need to actually know what the targets do. CHANGES SINCE LAST ACTION https://reviews.llvm.org/D108643/new/ https://reviews.llvm.org/D108643 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
