> Date: Wed, 15 May 2024 11:38:58 +0200 (CEST) > From: Richard Biener <rguent...@suse.de>
> The following removes the profile based heuristic limiting sinking > and instead uses post-dominators to avoid sinking to places that > are executed under the same conditions as the earlier location which > the profile based heuristic should have guaranteed as well. > > To avoid regressing this moves the empty-latch check to cover all > sink cases. > > It also stream-lines the resulting select_best_block a bit but avoids > adjusting heuristics more with this change. gfortran.dg/streamio_9.f90 > starts execute failing with this on x86_64 with -m32 because the > (float)i * 9.9999...e-7 compute is sunk across a STOP causing it > to be no longer spilled and thus the compare failing due to excess > precision. The patch adds -ffloat-store to avoid this, following > other similar testcases. > > This change doesn't fix the testcase in the PR on itself. It may come as no surprise that this patch (commit r15-518-g99b1daae18c095) caused a regression for some codes, for some targets. I entered PR115144 for the one that came to my attention. TL;DR: not sure what to do about it, if anything; it corresponds to the random_bitstring function in gcc.c-torture/execute/arith-rand-ll.c compiled for cris-elf with -O2 -march=v10 but there's no regression for coremark. The random_bitstring code does intense operations on "long long", i.e. lots of int64_t two-register operations and arithmetic library calls. I'd be grateful if you had a quick glance at random_bitstring in gcc.c-torture/execute/arith-rand-ll.c in case that code rings a bell related to the r15-518 change; maybe there's a trivial improvement you see. brgds, H-P
