On Mon, 6 Jan 2025, Richard Sandiford wrote: > > This was approved by Richard Sandiford in v1, so I'll commit it along with > > 6/7, which relies on it. > > Still stands, but I didn't think of this before, so thought I'd ask:
Sure, it's never wrong to revisit things as new ideas pop in. > Would it also work to record max_label_num () before RA and then > compare that recorded value with max_label_num () after RA? > Or would that have too many false positives? So it took me a little while to come up with a feasible way to check your proposal, but the combination of an unloaded mind and riding a chairlift made me come up with a solution. I wrote an experimental change tracking the label count before vs after RA and causing a warning to be emitted if it triggered. No warnings have been produced in full binutils/GCC/glibc toolchain builds for the `alpha-linux-gnu', `i386-linux-gnu', or `riscv64-linux-gnu' targets, all of which included an initial native `powerpc64le-linux-gnu' GCC bootstrap. There have been no regressions and certainly not of the ICE kind in the C frontend testsuite with the `alpha-linux-gnu' target and `-msafe-bwa -msafe-partial' options; one of the test cases did trigger the warning though, showing that this approach works. The warning also showed 8 times in my Alpha/Linux kernel `-msafe-bwa -msafe-partial' build. I'm yet running full `alpha-linux-gnu', `i386-linux-gnu', and `riscv64-linux-gnu' GCC regression testing, expected to complete sometime tomorrow, but I'm now fairly confident there will be no false positives at all. The thing is whether such a middle-end change can be safely accepted so far as we are now into Stage 4. I do hope it can, because the worst that could happen it would seem is there will be superfluous runs of basic block splitting. In any case I'll be posting v3 shortly, also including updates discussed with Jeff to 6/7 and 7/7, and it can be decided in discussion there. Thank you for your suggestion overall. NB I do recommend the chairlift method where feasible in solving issues; cf. <https://www.youtube.com/watch?v=Yv4tI6939q0>. Maciej
