[llvm] [GlobalISel][LLT] Introduce FPInfo for LLT (Enable bfloat, ppc128float and others in GlobalISel) (PR #155107)

via llvm-commits llvm-commits at lists.llvm.org
Mon Jan 12 03:44:00 PST 2026


DenisGZM wrote:

> I've encountered a few new issues when porting the AArch64 backend to use the new types.

Thank you for your help and valuable research.

> there are places in common infrastructure that build types. Currently these build generic scalars which breaks backends with extended types enabled. Switching these constructors to construct the extended type causes the non-extended backends to fail.

To be honest, I'm not familiar with this infrastructure, so can't be sure. But if there are places that are common for different backend and they are pregenerated, then having wrappers that may fallback seems reasonable.

> Please note the changes to `changeElementSize`. Being able to mutate the size of floating point types is very useful to have, as it can otherwise be quite cumbersome to check what type of float (bfloat, ppcf128, IEEE etc) is being used and creating the correct type.

I'm still don't know about `changeElementSize` for floating point. Well, it may be valid and I see how it could be used if we only consider IEEE fp types. But for custom types it feels wrong

>     if (isFloat() && getFpSemantics() != APFloatBase::S_BFloat)
>       return LLT::floatIEEE(NewEltSize);
> 
>     if (isFloat() && getFpSemantics() == APFloatBase::S_BFloat)
>       return LLT{Kind::FLOAT,
>                  isVector() ? getElementCount() : ElementCount::getFixed(0),
>                  NewEltSize, FpSemantics::S_BFloat};

I believe we don't want to see 32-bit bfloat at any point as it doesn't make sence



https://github.com/llvm/llvm-project/pull/155107


More information about the llvm-commits mailing list