On 17/02/2025 13:54, Richard Earnshaw (lists) wrote: > 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.
For example, can you set TODO_cleanup_cfg on your pass and then run it, say right after the final BB re-org pass? R.
