LLT: Add some stub constructors for FP types

[arsenm]

Summary

This is to start documenting uses to ease a future migration
to supporting different types with the same size.

[aemerson]

Did we decide on different types as the route for this? I'm still wondering if somehow adding more semantic operands to FP operations would be less intrusive.

[Pierre-vh]

I'm a bit neutral regarding this change, I can't comment on whether it's better to have the information in the types or the operations.
Though I'm also wondering if binding the semantics to FP operation wouldn't make more sense?

However if we're going this direction I would prefer to see all relevant uses of LLT::scalar looked at and replaced with ::float where needed (not just within the AMD backend) to avoid further fragmentation.

llvm/include/llvm/CodeGen/LowLevelType.h

74

small nit: I would add that to make it clear those ctors were added with the intention of going that way later.

[arsenm]

In D150605#4343994, @aemerson wrote:

Did we decide on different types as the route for this? I'm still wondering if somehow adding more semantic operands to FP operations would be less intrusive.

I thought previous discussions on this were coalescing around adding something to LLT, but not the details of how that would look. My feeling is adding FP semantics to the operations would require more code on average, plus additional costs from operating differently from the high level IR

[arsenm]

In D150605#4344853, @Pierre-vh wrote:

However if we're going this direction I would prefer to see all relevant uses of LLT::scalar looked at and replaced with ::float where needed (not just within the AMD backend) to avoid further fragmentation.

This isn't a complete set for AMDGPU either, and I don't see how it's fragmenting since this is just documenting at this point. Documenting FP uses like this will allow incrementally moving to a state where it's easier to introduce the new types

[qcolombet]

I'm still wondering if somehow adding more semantic operands to FP operations would be less intrusive.

I don't think that would be enough because we have to deal with the values at the ABI boundaries. I.e., there may not be an operation to attach the information to.

[qcolombet]

On a second thought the ABI concerns are probably fine because we can get the information directly from the LLVM IR.

If we were to go with the different opcodes for the different floating types, we would probably need to make RegBankSelect better.
With the proliferation of FP types (I think there are at least 3 different FP8 implementation at this point), we would end up with a lot of opcodes.

[aemerson]

In D150605#4344953, @arsenm wrote:

In D150605#4343994, @aemerson wrote:

Did we decide on different types as the route for this? I'm still wondering if somehow adding more semantic operands to FP operations would be less intrusive.

I thought previous discussions on this were coalescing around adding something to LLT, but not the details of how that would look. My feeling is adding FP semantics to the operations would require more code on average, plus additional costs from operating differently from the high level IR

Yeah it did, but it's going to be a lot of work either way. I'm not opposed to this in principle though.

In D150605#4345232, @qcolombet wrote:

On a second thought the ABI concerns are probably fine because we can get the information directly from the LLVM IR.

Right, we already deal with this correctly with untyped scalars so nothing would get worse.

If we were to go with the different opcodes for the different floating types, we would probably need to make RegBankSelect better.
With the proliferation of FP types (I think there are at least 3 different FP8 implementation at this point), we would end up with a lot of opcodes.

Sure, my idea was something more akin to:
%dst = G_FADD %src1:(s64), %src2, F64 where F64 is a sort of symbolic operand that encodes the semantics of the operation without requiring a whole new class of instructions.

[tschuett]

static constexpr LLT bfloat16() {
   return scalar(16);
 }

???

[arsenm]

In D150605#4346990, @tschuett wrote:

static constexpr LLT bfloat16() {
   return scalar(16);
 }

???

Someday, when these actually do something besides create a scalar. Currently bfloat just miscompiles

[tschuett]

Could you store an enum in LLT for the vast range of current and future floating point kinds?

[arsenm]

In D150605#4347050, @tschuett wrote:

Could you store an enum in LLT for the vast range of current and future floating point kinds?

That's what I was thinking. For all practical purposes we have excess bits for size/element count to steal some (although we do break on cases where we can't represent an IR type in LLT. We'd need an EVT equivalent referring back to an IR type to handle 100% of types the DAG can deal with)

[tschuett]

The innovative floating types ended in ApFloat and MLIR. I would be surprised if the number of floating point types in LLVM rapidly increases.

[bogner]

I think this is a reasonable thing to do assuming we're going in the direction of having FP info in the LLT rather than the ops (As was my suggestion way back here: https://discourse.llvm.org/t/rfc-globalisel-representing-fp-types-in-llt/57162). The main downside is that since it's just the API without any semantics with this change it could make things hard to debug if someone gets them wrong, but it's probably still better than having to migrate wholesale from having no types at all.

[aemerson]

If we're going down this path, (which is ok with me), should we have a migration plan for this change? I'm thinking we start a thread on discourse to talk about intermediate steps. The last time I attempted this it got very hairy, very quickly. I'd like us to have a path where we can make incremental changes over time with robust verification, and get to a place where we can have a switch that we can flip for testing purposes before we enable permanently.

[arsenm]

Rebase

[bogner]

LGTM. Have you thought about @aemerson's suggestion about a migration plan?

[arsenm]

In D150605#4634972, @bogner wrote:

LGTM. Have you thought about @aemerson's suggestion about a migration plan?

That's sort of the point of this. We can incrementally start documenting where FP types are supposed to be used with these. Later we can have a switch for making these do something different

[arsenm]

77c67436d9e7e63c50752d990a271cf860ba9a0e

llvm/include/llvm/CodeGen/LowLevelType.h

static constexpr LLT vector(ElementCount EC, LLT ScalarTy) {
     return LLT{ScalarTy.isPointer(),
                /*isVector=*/true,
                /*isScalar=*/false,
                EC,
                ScalarTy.getSizeInBits().getFixedValue(),
                ScalarTy.isPointer() ? ScalarTy.getAddressSpace() : 0};
   }
 
+  /// Get a 16-bit IEEE half value.
+  /// TODO: Add IEEE semantics to type - This currently returns a simple `scalar(16)`.
+  static constexpr LLT float16() {
+    return scalar(16);
+  }
+
+  /// Get a 32-bit IEEE float value.
+  static constexpr LLT float32() {
+    return scalar(32);
+  }
+
+  /// Get a 64-bit IEEE double value.
+  static constexpr LLT float64() {
+    return scalar(64);
+  }
+
   /// Get a low-level fixed-width vector of some number of elements and element
   /// width.
   static constexpr LLT fixed_vector(unsigned NumElements,
                                     unsigned ScalarSizeInBits) {
     return vector(ElementCount::getFixed(NumElements), ScalarSizeInBits);
   }
 
   /// Get a low-level fixed-width vector of some number of elements and element

llvm/lib/Target/AMDGPU/AMDGPULegalizerInfo.cpp

bool AMDGPULegalizerInfo::legalizeFMad(
   LLT Ty = MRI.getType(MI.getOperand(0).getReg());
   assert(Ty.isScalar());
 
   MachineFunction &MF = B.getMF();
   const SIMachineFunctionInfo *MFI = MF.getInfo<SIMachineFunctionInfo>();
 
   // TODO: Always legal with future ftz flag.
   // FIXME: Do we need just output?
-  if (Ty == LLT::scalar(32) &&
+  if (Ty == LLT::float32() &&
       MFI->getMode().FP32Denormals == DenormalMode::getPreserveSign())
     return true;
-  if (Ty == LLT::scalar(16) &&
+  if (Ty == LLT::float16() &&
       MFI->getMode().FP64FP16Denormals == DenormalMode::getPreserveSign())
     return true;
 
   MachineIRBuilder HelperBuilder(MI);
   GISelObserverWrapper DummyObserver;
   LegalizerHelper Helper(MF, DummyObserver, HelperBuilder);
   return Helper.lowerFMad(MI) == LegalizerHelper::Legalized;
 }

 
 bool AMDGPULegalizerInfo::legalizeFPow(MachineInstr &MI,
                                        MachineIRBuilder &B) const {
   Register Dst = MI.getOperand(0).getReg();
   Register Src0 = MI.getOperand(1).getReg();
   Register Src1 = MI.getOperand(2).getReg();
   unsigned Flags = MI.getFlags();
   LLT Ty = B.getMRI()->getType(Dst);
-  const LLT S16 = LLT::scalar(16);
-  const LLT S32 = LLT::scalar(32);
+  const LLT F16 = LLT::float16();
+  const LLT F32 = LLT::float32();
 
-  if (Ty == S32) {
-    auto Log = B.buildFLog2(S32, Src0, Flags);
-    auto Mul = B.buildIntrinsic(Intrinsic::amdgcn_fmul_legacy, {S32})
+  if (Ty == F32) {
+    auto Log = B.buildFLog2(F32, Src0, Flags);
+    auto Mul = B.buildIntrinsic(Intrinsic::amdgcn_fmul_legacy, {F32})
                    .addUse(Log.getReg(0))
                    .addUse(Src1)
                    .setMIFlags(Flags);
     B.buildFExp2(Dst, Mul, Flags);
-  } else if (Ty == S16) {
+  } else if (Ty == F16) {
     // There's no f16 fmul_legacy, so we need to convert for it.
-    auto Log = B.buildFLog2(S16, Src0, Flags);
-    auto Ext0 = B.buildFPExt(S32, Log, Flags);
-    auto Ext1 = B.buildFPExt(S32, Src1, Flags);
-    auto Mul = B.buildIntrinsic(Intrinsic::amdgcn_fmul_legacy, {S32})
+    auto Log = B.buildFLog2(F16, Src0, Flags);
+    auto Ext0 = B.buildFPExt(F32, Log, Flags);
+    auto Ext1 = B.buildFPExt(F32, Src1, Flags);
+    auto Mul = B.buildIntrinsic(Intrinsic::amdgcn_fmul_legacy, {F32})
                    .addUse(Ext0.getReg(0))
                    .addUse(Ext1.getReg(0))
                    .setMIFlags(Flags);
-
-    B.buildFExp2(Dst, B.buildFPTrunc(S16, Mul), Flags);
+    B.buildFExp2(Dst, B.buildFPTrunc(F16, Mul), Flags);
   } else
     return false;
 
   MI.eraseFromParent();
   return true;
 }
 
 // Find a source register, ignoring any possible source modifiers.
 static Register stripAnySourceMods(Register OrigSrc, MachineRegisterInfo &MRI) {
   Register ModSrc = OrigSrc;
   if (MachineInstr *SrcFNeg = getOpcodeDef(AMDGPU::G_FNEG, ModSrc, MRI)) {
     ModSrc = SrcFNeg->getOperand(1).getReg();
     if (MachineInstr *SrcFAbs = getOpcodeDef(AMDGPU::G_FABS, ModSrc, MRI))
       ModSrc = SrcFAbs->getOperand(1).getReg();
   } else if (MachineInstr *SrcFAbs = getOpcodeDef(AMDGPU::G_FABS, ModSrc, MRI))
     ModSrc = SrcFAbs->getOperand(1).getReg();
   return ModSrc;
 }
 
 bool AMDGPULegalizerInfo::legalizeFFloor(MachineInstr &MI,
                                          MachineRegisterInfo &MRI,
                                          MachineIRBuilder &B) const {
 
   const LLT S1 = LLT::scalar(1);
-  const LLT S64 = LLT::scalar(64);
+  const LLT F64 = LLT::float64();
   Register Dst = MI.getOperand(0).getReg();
   Register OrigSrc = MI.getOperand(1).getReg();
   unsigned Flags = MI.getFlags();
-  assert(ST.hasFractBug() && MRI.getType(Dst) == S64 &&
+  assert(ST.hasFractBug() && MRI.getType(Dst) == F64 &&
          "this should not have been custom lowered");
 
   // V_FRACT is buggy on SI, so the F32 version is never used and (x-floor(x))
   // is used instead. However, SI doesn't have V_FLOOR_F64, so the most
   // efficient way to implement it is using V_FRACT_F64. The workaround for the
   // V_FRACT bug is:
   //    fract(x) = isnan(x) ? x : min(V_FRACT(x), 0.99999999999999999)
   //
   // Convert floor(x) to (x - fract(x))
 
-  auto Fract = B.buildIntrinsic(Intrinsic::amdgcn_fract, {S64})
+  auto Fract = B.buildIntrinsic(Intrinsic::amdgcn_fract, {F64})
                    .addUse(OrigSrc)
                    .setMIFlags(Flags);
 
   // Give source modifier matching some assistance before obscuring a foldable
   // pattern.
 
   // TODO: We can avoid the neg on the fract? The input sign to fract
   // shouldn't matter?
   Register ModSrc = stripAnySourceMods(OrigSrc, MRI);
 
   auto Const =
-      B.buildFConstant(S64, llvm::bit_cast<double>(0x3fefffffffffffff));
+      B.buildFConstant(F64, llvm::bit_cast<double>(0x3fefffffffffffff));
 
-  Register Min = MRI.createGenericVirtualRegister(S64);
+  Register Min = MRI.createGenericVirtualRegister(F64);
 
   // We don't need to concern ourselves with the snan handling difference, so
   // use the one which will directly select.
   const SIMachineFunctionInfo *MFI = B.getMF().getInfo<SIMachineFunctionInfo>();
   if (MFI->getMode().IEEE)
     B.buildFMinNumIEEE(Min, Fract, Const, Flags);
   else
     B.buildFMinNum(Min, Fract, Const, Flags);
 
   Register CorrectedFract = Min;
   if (!MI.getFlag(MachineInstr::FmNoNans)) {
     auto IsNan = B.buildFCmp(CmpInst::FCMP_ORD, S1, ModSrc, ModSrc, Flags);
-    CorrectedFract = B.buildSelect(S64, IsNan, ModSrc, Min, Flags).getReg(0);
+    CorrectedFract = B.buildSelect(F64, IsNan, ModSrc, Min, Flags).getReg(0);
   }
 
-  auto NegFract = B.buildFNeg(S64, CorrectedFract, Flags);
+  auto NegFract = B.buildFNeg(F64, CorrectedFract, Flags);
   B.buildFAdd(Dst, OrigSrc, NegFract, Flags);
 
   MI.eraseFromParent();
   return true;
 }
 
 // Turn an illegal packed v2s16 build vector into bit operations.
 // TODO: This should probably be a bitcast action in LegalizerHelper.