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

[Ryan Cowan via llvm-commits]

HolyMolyCowMan wrote:

The float changes look okay to me, but, it was nice to be able to declare floats directly by size & standard.

I was thinking that we might need to change some of the legalizer mutations in `LegalizerInfo.h`, there are a lot of mutations that claim to be changing size but also modify the type when we enable extended types.

For example, if we define a minScalar action and supply a scalar type (e.g. s32), the type will be changed to s32, instead of just widened to 32 bits.
```
  LegalizeRuleSet &minScalar(unsigned TypeIdx, const LLT Ty) {
    using namespace LegalityPredicates;
    using namespace LegalizeMutations;
    return actionIf(LegalizeAction::WidenScalar,
                    scalarNarrowerThan(TypeIdx, Ty.getSizeInBits()),
                    changeTo(typeIdx(TypeIdx), Ty));
  }
 ```
 
I think we could just change the `changeTo` in this instance to something like: `changeElementSizeTo(typeIdx(TypeIdx), Ty));`. There might need to be more nuance with some of the other actions.

Similarly, there are a lot of places that construct scalars directly, this is of course something that will need to be remedied by each backend before enabling this. There may be a problem there however. As far as I understand, the shared infrastructure (like LegalizerInfo) sometimes contain these calls to the scalar constructor which can cause issues with extended types enabled. We can't change these constructors to extended types without breaking backends with it disabled. I was thinking we could try to remedy this by adding a check to each of the constructors for the extended types & creating a scalar if the extended types are disabled, at the very least that means that non-extended backends get a little more context around expected/intended types?

> As I see, if only use extended types with match tables generated for extended LLT, this problem may be avoided. Or we need to update logic in MatchTableEmitter to allow continue matching.

I think you might be right, some of the issues I have been encountering have been caused by other issues. I still feel that allowing extended types to match with generic scalars would be a nice feature to have.


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