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

[Matt Arsenault via llvm-dev]

> On Dec 8, 2020, at 14:02, Justin Bogner <mail at justinbogner.com> wrote:
> 
> 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)
> 

Yes, I think encoding the FP mode would be overkill. I do think we shouldn’t go too far into treating these as FP types mirroring the IR though. I would still like to be able to directly operate on these with integer operations without intermediate bitcasts. Only lowerings which really care about the FP semantics would need to treat these differently.

I do think threading these through all the existing legalizer code could be painful, since quite a few places create out of context scalar types whereas now they would need to take care to pass through the FP-bits.

-Matt