> Date: Mon, 27 May 2024 12:57:53 -0600 > From: Jeff Law <jeffreya...@gmail.com>
> > * resource.cc: Include cfgrtl.h. Use BLOCK_FOR_INSN (insn)->index > > instead of calling find_basic_block (insn). Assert for not -1. > > (find_basic_block): Remove function. > > (init_resource_info): Call compute_bb_for_insn. > > (free_resource_info): Call free_bb_for_insn. > I'm pretty sure that code as part of the overall problem -- namely that > we didn't have good basic block info so we resorted to insn scanning. > > Presumably we set BLOCK_FOR_INSN when we generate a wrapper SEQUENCE > insns for a filled delay slot? Yes - one way or the other: most insn chain changes from reorg are through calls to add_insn_after, which always sets the bb of the added insn according to the reference insn (except when either insn is a barrier, then it never sets a bb); see for example emit_delay_sequence. Others by emit_insn_before and emit_copy_of_insn_after. (Not-so-)fun fact: add_insn_after takes a bb parameter which reorg.cc always passes as NULL. But - the argument is *always ignored* and the bb in the "after" insn is used. I traced that ignored parameter as far as r0-81421-g6fb5fa3cbc0d78 "Merge dataflow branch into mainline" when is was added. I *guess* it's an artifact left over from some idea explored on that branch. Ripe for obvious cleanup by removal everywhere. > Assuming we do create the right mapping > for those new insns, then this is OK. Thanks for the quick review of the whole set! brgds, H-P
