https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68695
Jakub Jelinek <jakub at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |jakub at gcc dot gnu.org,
| |vmakarov at gcc dot gnu.org
--- Comment #20 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
To me this looks like a poor job done by IRA.
There is nothing if-conversion does (before/after r226901, which is the latest
version of the coalescing/copyrename changes, r224262 just ICEs on this
testcase) on these testcases on s390x.
Perhaps better testcase:
int
foo (int x, int y, int a, int b)
{
int i = x;
int j = y;
if (x > y)
{
i = a;
j = b;
}
return i * j;
}
We end up before IRA with if-then-else, with 6 pseudos, where 4 of them are
REG_DEAD inside of the then or else, and IRA decides on the following
dispositions:
r60 i %r2
r61 j %r5
r62 x %r2
r63 y %r3
r64 a %r4
r65 b %r5
The dispositions for the arguments are obviously right, that is where the
arguments live, but for i/j, this is a very bad choice. As Segher said,
presumably IRA attempts to assign i/j so that in each cases one of the
assignments becomes a nop, which it managed to do, but what is wrong is that it
picks up one assignment in the then block and one assignment in the else block
to be come nop. Much better would be to either pick
r60 i %r2
r61 j %r3
or
r60 i %r4
r61 j %r5
(which one really shouldn't matter much on this testcase, and both are
possible), then either the if or then block become a nop.
Tweaking coalescing for this, while perhaps possible, would mean if we run into
similar case during RA with for whatever other reason not coalesced pseudos we
run into this again. Presumably if __builtin_expect is used, IRA should prefer
assignments in the more likely blocks, attempting harder to make them nops.
