https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104581
--- Comment #9 from rguenther at suse dot de <rguenther at suse dot de> --- On Thu, 17 Feb 2022, jakub at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104581 > > --- Comment #7 from Jakub Jelinek <jakub at gcc dot gnu.org> --- > Ah, you're right. > So, can't it instead of the quadratic walk just compare DF_INSN_LUID? > If it isn't right after df_analyze and some insns could have been added in > between, it would need to maintain the luids somehow (perhaps e.g. in the way > how we do it in tree-ssa-reassoc.cc, if we add insns, we must set their uid to > either the previous or next insn's uid and then can do some IL walk, but only > as long as the uid is the same, so unless everything in the bb changes it > should be still cheap. I think this "feature" needs to be better integrated with the mode-switching data-flow. It's too much bolted-on and thus has unnecessarily high complexity. In particular this is the initial local analysis run of mode-switching where it just computes mode_in/mode_out of a BB (but the target hooks do not have the pass meta data available). The first calls to the hook are from if (targetm.mode_switching.entry && targetm.mode_switching.exit) { /* Split the edge from the entry block, so that we can note that there NORMAL_MODE is supplied. */ post_entry = split_edge (single_succ_edge (ENTRY_BLOCK_PTR_FOR_FN (cfun))); pre_exit = create_pre_exit (n_entities, entity_map, num_modes); which even runs before df_analyze () so if the DF walk would be triggered there it definitely looks bogus. I also see nothing adding the chain problem (I dn't remember which ones are added by default though).
