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

[Daniel Sanders via llvm-dev]

> On Dec 9, 2020, at 02:28, Jay Foad via llvm-dev <llvm-dev at lists.llvm.org> wrote:
> 
> On Tue, 8 Dec 2020 at 19:04, Justin Bogner via llvm-dev
> <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> 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)
>> 
>> 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
> 
> I strongly agree!
> 
> Jay.

+1 but I don't think the public API should reveal that (e.g. we shouldn't have an isVariantFloat()). I think that should still lean towards isFloat(), isBFloat(), getMantissaSizeInBits(), etc. in the API so that we can avoid changing the API if we grow more interesting types in the future.

> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev <https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20201215/b130cd80/attachment.html>