Page MenuHomePhabricator

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

Authored by etherzhhb on Jan 17 2018, 11:13 AM.

Details

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.

Diff Detail

Repository
rL LLVM

Event Timeline

etherzhhb created this revision.Jan 17 2018, 11:13 AM
etherzhhb edited the summary of this revision. (Show Details)Jan 17 2018, 11:44 AM

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

etherzhhb updated this revision to Diff 130263.Jan 17 2018, 1:22 PM

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

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?

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
1044–1045

Update this comment?

1100–1104

Would you want to modify this check too?

1128–1129

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

etherzhhb added a comment.EditedJan 17 2018, 4:03 PM

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
1044–1045

Yes

1100–1104

yes

1128–1129

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

etherzhhb updated this revision to Diff 130494.Jan 18 2018, 2:23 PM

Address Hal's comment

etherzhhb updated this revision to Diff 130495.Jan 18 2018, 2:30 PM
etherzhhb marked 2 inline comments as done.

Fix typo

etherzhhb marked 4 inline comments as done.Jan 18 2018, 2:32 PM
silvas resigned from this revision.Mar 25 2020, 6:25 PM