On 10/11/26 4:56 PM, Yongqiang Tian wrote:
relax_delay_slots checks whether a BARRIER immediately precedes a jump
target at two sites. pass_cleanup_barriers can place a DEBUG_INSN
between the BARRIER and CODE_LABEL, so prev_nonnote_insn makes both
decisions depend on whether debug information is present.
Use prev_nonnote_nondebug_insn for both queries. Add two SPARC tests
covering the separate decisions.
This follows up Jeff Law's review of the patch for PR127795, which
pointed out that these BARRIER queries could potentially depend on
DEBUG_INSN placement. I initially replied that I had not seen GCC put
a DEBUG_INSN in that position. Further investigation showed that
pass_cleanup_barriers can create exactly that sequence, so this patch
corrects that earlier conclusion.
Tested at GCC revision a02e2004cb707155d5b9b0a82dd428ded0ee2f6f:
* Instrumented baseline runs confirm that the first and second SPARC
tests reach the first and second modified queries, respectively.
Both fail without this patch and pass with it.
* A complete sparc-elf `make -k -j8 check-gcc` comparison has no
regressions.
* Native x86_64-pc-linux-gnu `make -j24 bootstrap` and
`make -k -j24 check` completed with and without the two-patch series.
After normalizing build paths, both produced the same outcomes:
621579 PASS, 6 FAIL, 1 XPASS, 4872 XFAIL, and 8114 UNSUPPORTED.
* `contrib/check_GNU_style.sh` and `git diff --check` pass.
Assisted-by: OpenAI Codex 5.6 Sol, co-reviewed by Claude and Yongqiang Tian.
PR rtl-optimization/127808
gcc/ChangeLog:
* reorg.cc (relax_delay_slots): Ignore debug insns when looking for
a BARRIER before a jump target.
gcc/testsuite/ChangeLog:
* gcc.target/sparc/reorg-relax-barrier-debug-1.c: New test.
* gcc.target/sparc/reorg-relax-barrier-debug-2.c: New test.
Signed-off-by: Yongqiang Tian <[email protected]>
Thanks. I've pushed this to the trunk.
It's worth noting that LLM review had some concerns about NULL pointer
dereferences, but I don't think those cases can happen.
If you want to keep chasing these kinds of things, look in
skip_consecutive_labels. If we were to have something like
CODE_LABEL
DEBUG_INSN
CODE_LABEL
BARRIER
Then I think first loop can exit based on the existence of the
DEBUG_INSN (due to the !INSN_P check). I don't know if this happens in
practice.
There may be problems in find_basic_block as well (resource.cc). There's
probably more given reorg.cc's history (written before we had
DEBUG_INSNs) and isn't as widely used as delay slots aren't that common.
Jeff
