On 17/02/2025 12:42, H.J. Lu wrote: > On Mon, Feb 17, 2025 at 7:08 PM Richard Earnshaw (lists) > <richard.earns...@arm.com> wrote: >> >> On 13/02/2025 21:43, H.J. Lu wrote: >>> Increment LABEL_NUSES when using minipool_vector_label to avoid the zero >>> use count on minipool_vector_label. >>> >>> PR target/118866 >>> * config/arm/arm.cc (arm_reorg): Increment LABEL_NUSES when >>> using minipool_vector_label. >>> >> >> Whilst this patch isn't wrong per se, I'm concerned that it's likely due to >> something else violating the assumptions that a >> TARGET_MACHINE_DEPENDENT_REORG pass implementation is entitled to make. On >> arm, the insertion of minipools in the code has to assume that the BB layout >> won't change after that point (otherwise the offset calculations will be >> wrong). In fact, only changes that reduce code size within a single basic >> block are going to be safe at this point. >> >> So what's changed to make this patch needed, and is it being run too late? >> >> R. > > I am working on: > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47253 > > After a sibcall is folded into a conditional branch, the old > conditional branch target label becomes used. But the > basic block can't be removed if it is still reachable. In this > case, I'd like to change final_scan_insn_1 to skip the > code label if its LABEL_NUSES is 0. This means that > all referenced labels should have their LABEL_NUSES != 0. > I will find another way to deal with it. > > -- > H.J.
Right, but why does detection of this need to be delayed until after md_reorg has been run? Can't the pass be done much earlier? I'm just concerned about the ordering of the passes, something that has the potential to re-arrange code like this could mess up the assumptions that the md_reorg pass has to make. R.
