erichkeane added a comment. 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. Or am I missing something here? The only difference here that I can see vs bool is that we don't do anything for in-function variables: ; Function Attrs: mustprogress noinline nounwind optnone define dso_local signext i5 @_Z3BarDB5_(i5 signext %b) #0 { entry: %b.addr = alloca i5, align 1 %c = alloca i5, align 1 store i5 %b, i5* %b.addr, align 1 %0 = load i5, i5* %b.addr, align 1 store i5 %0, i5* %c, align 1 %1 = load i5, i5* %c, align 1 ret i5 %1 } ; Function Attrs: mustprogress noinline nounwind optnone define dso_local zeroext i5 @_Z3BazDU5_(i5 zeroext %b) #0 { entry: %b.addr = alloca i5, align 1 %c = alloca i5, align 1 store i5 %b, i5* %b.addr, align 1 %0 = load i5, i5* %b.addr, align 1 store i5 %0, i5* %c, align 1 %1 = load i5, i5* %c, align 1 ret i5 %1 } 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