[PATCH] D36795: [SystemZ] Increase number of LOCRs emitted by passing regalloc hints

Jonas Paulsson via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Mon Sep 11 01:24:46 PDT 2017


jonpa added a comment.

In https://reviews.llvm.org/D36795#865237, @qcolombet wrote:

> The generic change looks fine though it sounds surprising that anyone would want that.
>
> The problem here is that copies are super expensive when those hints are not fulfill, right?


Thanks for review. Well, instead of a conditional move implemented with one instruction, we would get a jump sequence over a block containing just one move instruction. This *may* be very bad in an inner loop. In particular, this is what happened when I applied Weis reg-split patch and got a significant regression.

SystemZ has BTW more instructions which could be implemented the same way: a "mux" pseudo of the GRX32 regclass which would then be expanded into an instruction using either high or low parts, depending on the choice of registers RA did. I don't think all those instructions waiting to be implemented in the backend would necessarily suffer as much as the load-on-condition, so it is a matter of judgment if using the "hard hints" is better or worse. If one were to judge this based on the number of spilled live ranges, this seems to work fine for the LOCR case, as can be seen in the table above. Do you think that looking at the number of spilled live ranges is a good way to consider the trade-off for using hard hints, or do you perhaps have anything to add?

It would have been nice to *guarantee* that the pseudo will get either high or low parts, like gcc will let you specify combinations of legal register operands. If that could be done, SystemZ could even remove its custom pass that handles any rare cases of mixed operands. But I suppose this would not be easy to do, or?


https://reviews.llvm.org/D36795





More information about the llvm-commits mailing list