[llvm-dev] RFC: [GlobalISel] Representing fp types in LLT

[Justin Bogner via llvm-dev]

For a while now there have been discussions here and there about
representing floating point types explicitly in LLT. Having this type
information explicitly makes RegBankSelect easier to implement, avoids
inefficiencies in disambiguating which operation is needed to lower
various operations, and is necessary for correctness in light of variant
floating point types like bfloat.

I believe there is general consensus that we need this, so this RFC is
about how we should go about modeling these types.

At the dev meeting, we discussed two approaches IIRC:

1. Explicitly encode the number of bits in the exponent and mantissa for
   flexibility
2. Encode only the types we need (ie, model the same fp types as
   llvm::Type does)

The idea with (1) was that this way we could easily handle IEEE-754
binary formats and variants like bfloat16 and tf32 without needing to
burden ISel with knowledge of specifics. The major drawback of this is
that it would struggle to represent types that don't fit the general
mold, like ppc-fp128 (which is two doubles) or the IEEE 754-2008 decimal
formats.

I think (2) is the safer way forward, and I propose that we can
implement it using only 2 extra bits in each of the scalar and vector
variants of LLT. This approach largely hinges on the fact that there are
very few interesting (that is, actively used) variants of floating point
for a given scalar size.

The two bits would be used like so:
```
enum FPInfo { NotFP = 0x0, FP = 0x1, Reserved = 0x2, VariantFP = 0x3 };
```

This uses one bit to say a scalar is floating point, which, when set
will imply that it's the "usual" format for the size, and a second bit
to say it's a variant for that size. There's space to handle two
different variants for a size in the `Reserved` case if we need it
later.

With this, we can model every floating point type that llvm IR does
today (half, bfloat16, single, double, x86-fp80, fp128, ppc-fp128), and
is easily extensible for things like fp256, tensorfloat, or IEEE-754
decimal floats should llvm need to support those explicitly in the
future.

Backends will need to be updated to handle these extra types. Notably,
the legalizer will need to be made more precise for operations like fadd
and isel will need to be aware of when any scalar will do or if the
distinction is important.

I've attached a patch for demonstration that adds fpscalar, bfloat, and
ppcf128 and implements printing, parsing, and conversion from llvm
IR. If folks are happy with this direction I'll start working on the
backend updates to get this fully working.

WDYT?

-------------- next part --------------
A non-text attachment was scrubbed...
Name: llt-float.patch
Type: text/x-patch
Size: 17006 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20201208/e118ec56/attachment.bin>