[PATCH] D72961: In early-ifconversion check that the operands of a PHI share a common regclass with the destination regclass.

Amara Emerson via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Fri Jan 17 19:36:47 PST 2020


aemerson added a comment.

In D72961#1827862 <https://reviews.llvm.org/D72961#1827862>, @efriedma wrote:

> > My initial reaction was that the PHI was invalid, but according to @qcolombet it's ok to have different register banks on the operands
>
> Okay... but the operand register class can't actually be *anything*, can it?  We have restrictions on COPY instructions.


Those restrictions are target specific though aren’t they? I think it’s the responsibility of ISel to generate valid copies and similar should apply to PHIs.

>> The problem here is that ifcvt tries to generate a target instruction, AArch64::CSELXr in place of the PHI with incompatible regclasses. If we leave it to PHI elimination it works fine.
> 
> I assume the reason PHI elimination works is that it inserts a cross-class COPY. We can do the same here.  The question would just be whether it's profitable; I guess we have to consider the cost of speculating a copy.

Yeah, we’d definitely need copy cost heuristics. FPR <-> GPR copies can be a 5 cycles on some AArch64 uarchs.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D72961/new/

https://reviews.llvm.org/D72961





More information about the llvm-commits mailing list