labrinea added a comment.
Ok, I've tried a few things. If we add a couple of new target hooks we can make
clang pass both input and output asm operands by value as `type { [8 x i64] }`
avoiding the integer conversion. One issue with that is that the inline asm
verifier asserts if an inline asm statement returns a struct with one result
(struct return types are meant to carry multiple results). By making
adjustments to the existing target hook `adjustInlineAsmType()` we can even
alter the asm operand type and make it `[8 x i64]` for example if that's
preferable. Adding new calls to this hook without removing the existing ones
will look ugly though, but at the same time I found it challenging given the
complexity of the 400-line function `CodeGenFunction::EmitAsmStmt`, which needs
tidying up. Unfortunately this is half of the story as by choosing an aggregate
type for the asm operands we are allowing InstCombine (at -O1 and above) to
turn the load/store instructions before/after the inline asm statement into
insert/extract element + smaller loads/stores. I see two problems with that.
Firstly, the information that the load/store comes from an inline asm operand
gets lost by the time the SelectionDAG processes those nodes, and so we cannot
use a target hook to select a special value type for them (as discussed in
D94097 <https://reviews.llvm.org/D94097> we want to narrow down the MVT
specialization for an llvm type to only apply to asm operands and not
universally). Moreover, having insert/extract element is pointless when the
backend expects a load/store of `MVT::i64x8` for custom lowering. All that said
I think that the best choice is to use `i512` for the asm operands since llvm
cannot optimize that. The only change in clang's user visible behavior is that
large aggregate output operands will not be diagnosed, like in the example at
the description, but instead we'll be passing them by reference, which is what
is already happening with input operands anyway.
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D94098/new/
https://reviews.llvm.org/D94098
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
