https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115144
--- Comment #7 from Hans-Peter Nilsson <hp at gcc dot gnu.org> ---
(In reply to Richard Biener from comment #6)
> For gcc.c-torture/execute/arith-rand-ll.c, does it help to replace the exit
> (0) call with a return 0 statement?
No. FWIW, it also doesn't help renaming and wrapping main to xmain
__attribute__ noipa.
> 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[...]
Yes; see previous comments. I'd say the changes in random_bitstring are no
longer "interesting". I've also analyzed the unfilled delay-slot signalled by
gcc.target/cris/pr93372-47.c to be because of a bug in that pass. (Not the
same, but events are amusingly parallel to the bug that made me add that
test-case.)
> 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?
Sorry, I don't follow here, but I'm going to let that be, as random_bitstring
isn't interesting (except regarding the bug).
> 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?
Delay-slot-filling is unrelated to scheduling. It's in reorg.cc with its own
horribly outdated dataflow analysis in resource.cc (but used to be shared).
> That said, I think sinking now works as expected.
In random_bitstring I agree, but there's fallout in main.
> 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.
Thank you in advance and for the look this far! I haven't looked closer at
what happens with later passes in main, but looking at the generated assembly
code, the "sinking" of a division has the eventual effect of increasing
register pressure; see the previously attached dumps.
