[RFC] [TargetTransformInfo] Introduce isRegisterRich, it returns true if the target architecture is register-rich.

[etherzhhb]

Summary

Currently in the llvm middle-end, we disable some optimizations because we worry about the register pressure, (e.g. GVNHoist and ArgumentPromotion).

However, in the architecture that are register-rich, e.g. FPGAs, we do not need to worry about the register pressure at all. For these architecures, we may want to optimization the LLVM IR without worrying about the register pressure.

I suggest that we introduce a hook in the TargetTransformInfo to tell if the current target architecture is register-rich or not. With this hook, we can enable the optimizations that increase register pressure in case the current architecture is register-rich.

One problem for introducing this hook: we are not able to test it (in the public buildbot) without an register-rich target architecture in LLVM trunk, and unfortunately, we do not have one today.

To address this problem, I propose to add a command line option to enable the register-rich mode such that we can test the corresponding code path as well.

[kparzysz]

There is already a function getNumberOfRegisters. Would it be enough to return some large number from it?

[etherzhhb]

Implement isRegisterRich based on getNumberOfRegisters, and introduce a threshold to tell when the number of registers if big enough to be considered as "register-rich". Also include the usage of the isRegisterRich function in GVNHoist

[etherzhhb]

In D42191#979132, @kparzysz wrote:

There is already a function getNumberOfRegisters. Would it be enough to return some large number from it?

Yes, I think getNumberOfRegisters is sufficient. But instead of comparing getNumberOfRegisters with a large number in every passes, maybe we could introduce a function in TargetTransformInfo to do the comparison?

[hfinkel]

In part, it looks like you're looking to modify heuristics that prevent increased spilling around calls. I can imagine that, in general, architectures with lots of registers suffer from less of that, but that's really a statement about the ABI of the call, not the architecture itself.

Also, are you targeting FPGAs? Maybe this is better phrased in terms of architectures that don't have physical registers (we already have backend targets that have only virtual registers), because lacking physical registers, I can imagine register pressure being much less concerning. Arbitrary hoisting might not be great for FPGA HLS either, because of increased routing pressure and the like, but if we imagine that the backend can sink when useful, then maybe we're just making a statement about being reliant on that?

lib/Transforms/Scalar/GVNHoist.cpp

1045 ↗

(On Diff #130263)

Update this comment?

1101 ↗

(On Diff #130263)

Would you want to modify this check too?

1127 ↗

(On Diff #130263)

Is this comment accurate? I don't see why this is talking about calls here when calls are handled in the block above.

[etherzhhb]

In D42191#979308, @hfinkel wrote:

In part, it looks like you're looking to modify heuristics that prevent increased spilling around calls. I can imagine that, in general, architectures with lots of registers suffer from less of that, but that's really a statement about the ABI of the call, not the architecture itself.

The original motivation is about hoisting the GEP, in general I want to GVN the gep like:

bb0:
idx0 = i + 2
g0 = gep A, idx0
br bb2

bb1:
idx1 = i + 2
g1 = gep A, idx1
br bb2

bb2:
g = phi [g0, bb0]; [g1, bb1]

In this example, g1 and g2 is not GVNed because our concern about the register pressure (or address mode?).

Also, are you targeting FPGAs?

Yes

Maybe this is better phrased in terms of architectures that don't have physical registers (we already have backend targets that have only virtual registers), because lacking physical registers, I can imagine register pressure being much less concerning.
Arbitrary hoisting might not be great for FPGA HLS either, because of increased routing pressure and the like,

Not sure the place and route pressure, but too much registers may still have a negative impact on FPGAs.

but if we imagine that the backend can sink when useful, then maybe we're just making a statement about being reliant on that?

Yes.

I am thinking maybe some of the LLVM IR passes could provide a mode that run without the concern of physical constraints like register pressure, and simplify the dataflow of the LLVM IR as much as possible.

I am trying to identify the actual physical constraints that prevents simplification like GVN from happening, and try to make these constraints more explicit and provide a hook to relax these constraints if possible.

lib/Transforms/Scalar/GVNHoist.cpp

1045 ↗

(On Diff #130263)

Yes

1101 ↗

(On Diff #130263)

yes

1127 ↗

(On Diff #130263)

I guess it is about the address mode since it is related to GEP

[etherzhhb]

Address Hal's comment

[etherzhhb]

Fix typo

include/llvm/Analysis/TargetTransformInfo.h

     llvm_unreachable("Unknown instruction cost kind");
   }
 
+  /// \brief Return true if the target architecture is register-rich
+  bool isRegisterRich() const;
+
   /// \brief Underlying constants for 'cost' values in this interface.
   ///
   /// Many APIs in this interface return a cost. This enum defines the

   virtual int
   getUserCost(const User *U, ArrayRef<const Value *> Operands) = 0;
   virtual bool hasBranchDivergence() = 0;
+  virtual bool isRegisterRich() = 0;
   virtual bool isSourceOfDivergence(const Value *V) = 0;
   virtual bool isAlwaysUniform(const Value *V) = 0;
   virtual unsigned getFlatAddressSpace() = 0;

   int getUserCost(const User *U, ArrayRef<const Value *> Operands) override {
     return Impl.getUserCost(U, Operands);
   }
+  bool isRegisterRich() override { return Impl.isRegisterRich(); }
   bool hasBranchDivergence() override { return Impl.hasBranchDivergence(); }
   bool isSourceOfDivergence(const Value *V) override {
     return Impl.isSourceOfDivergence(V);

include/llvm/Analysis/TargetTransformInfoImpl.h

     }
   }
 
+  bool isRegisterRich() { return false; }
+
   bool hasBranchDivergence() { return false; }
 
   bool isSourceOfDivergence(const Value *V) { return false; }

lib/Analysis/TargetTransformInfo.cpp

   return Cost;
 }
 
+bool TargetTransformInfo::isRegisterRich() const {
+  return TTIImpl->isRegisterRich();
+}
+
 bool TargetTransformInfo::hasBranchDivergence() const {
   return TTIImpl->hasBranchDivergence();
 }