https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115144
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |law at gcc dot gnu.org
--- Comment #6 from Richard Biener <rguenth at gcc dot gnu.org> ---
For gcc.c-torture/execute/arith-rand-ll.c, does it help to replace the exit (0)
call with a return 0 statement?
Looking at gcc.target/cris/pr93372-47.c what we do here is sink tot_bits +=
n_bits into the else { of the in-loop conditional, in particular we sink
it right before the exit conditional in the loop. That's exactly what
we are supposed to do and the previous heuristic avoided because of the
guessed profile which is
if (n_bits_12 == 0)
goto <bb 4>; [5.50%]
else
goto <bb 5>; [94.50%]
thus the n_bits == 0 exit is unlikely and for some reason we thought
sinking across that isn't profitable.
To quote the loop in question is:
for (;;)
{
ran = simple_rand ();
n_bits = (ran >> 1) % 16;
tot_bits += n_bits;
if (n_bits == 0)
return x;
else
{
x <<= n_bits;
if (ran & 1)
x |= (1 << n_bits) - 1;
if (tot_bits > 8 * sizeof (long long) + 6)
return x;
}
}
Note that the sinking doesn't increase register lifetime (one of the reasons
of the previous heuristic), esp. if we'd go one step further and sink
to the start of the else { block rather than right before the exit
conditional. But I'd guess that wouldn't help the delay-slot filling here?
I've noticed CRIS doesn't support scheduling at all, so delay slot filling
(where's that done?) relies purely on our "random" scheduling we do at
RTL expansion time (via TER) and during GIMPLE optimization?
That said, I think sinking now works as expected. I do want to play with
sinking to the start of the else {, but without doing any lifetime analysis
I fear that's going to be worse in the average as the current location
at least ensures we're close to the first use of the DEF we sink.
