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

[Hal Finkel via Phabricator via llvm-commits]

hfinkel added a comment.

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?



================
Comment at: lib/Transforms/Scalar/GVNHoist.cpp:1045
         if (!allOperandsAvailable(Repl, DestBB)) {
           // When HoistingGeps there is nothing more we can do to make the
           // operands available: just continue.
----------------
Update this comment?


================
Comment at: lib/Transforms/Scalar/GVNHoist.cpp:1101
         // deeper may increase the register pressure and compilation time.
         if (MaxDepthInBB != -1 && InstructionNb++ >= MaxDepthInBB)
           break;
----------------
Would you want to modify this check too?


================
Comment at: lib/Transforms/Scalar/GVNHoist.cpp:1127
+        } else if (TTI.isRegisterRich() || !isa<GetElementPtrInst>(&I1))
           // Do not hoist scalars past calls that may write to memory because
           // that could result in spills later. geps are handled separately.
----------------
Is this comment accurate? I don't see why this is talking about calls here when calls are handled in the block above.


Repository:
  rL LLVM

https://reviews.llvm.org/D42191