[PATCH] D150605: LLT: Add some stub constructors for FP types

[Amara Emerson via Phabricator via llvm-commits]

aemerson added a comment.

In D150605#4344953 <https://reviews.llvm.org/D150605#4344953>, @arsenm wrote:

> In D150605#4343994 <https://reviews.llvm.org/D150605#4343994>, @aemerson wrote:
>
>> Did we decide on different types as the route for this? I'm still wondering if somehow adding more semantic operands to FP operations would be less intrusive.
>
> I thought previous discussions on this were coalescing around adding something to LLT, but not the details of how that would look. My feeling is adding FP semantics to the operations would require more code on average, plus additional costs from operating differently from the high level IR

Yeah it did, but it's going to be a lot of work either way. I'm not opposed to this in principle though.

In D150605#4345232 <https://reviews.llvm.org/D150605#4345232>, @qcolombet wrote:

> On a second thought the ABI concerns are probably fine because we can get the information directly from the LLVM IR.

Right, we already deal with this correctly with untyped scalars so nothing would get worse.

> If we were to go with the different opcodes for the different floating types, we would probably need to make `RegBankSelect` better.
> With the proliferation of FP types (I think there are at least 3 different FP8 implementation at this point), we would end up with a lot of opcodes.

Sure, my idea was something more akin to:
`%dst = G_FADD %src1:(s64), %src2, F64` where `F64` is a sort of symbolic operand that encodes the semantics of the operation without requiring a whole new class of instructions.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D150605/new/

https://reviews.llvm.org/D150605