https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116398
--- Comment #13 from rguenther at suse dot de <rguenther at suse dot de> --- On Fri, 14 Mar 2025, jakub at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116398 > > --- Comment #11 from Jakub Jelinek <jakub at gcc dot gnu.org> --- > Looking at df-scan.cc (df_recompute_luids), it uses INSN_P to determine what > should have luid assigned and so includes DEBUG_INSNs. > So DF_INSN_LUID difference can't be used for code generation, we'd need to > walk > from PREV_INSN (i3) back not counting DEBUG_INSN until we reach i2 or the > count > to punt on. > > Richi/Richard/Segher, thoughts on this? I suppose the BB walk in combine_instructions could count real insns and keep the allowed farthest away real insn recorded which we then can use to compare whether the candidate is before (off limit) or after (OK)? The re-starting possibly makes this a bit difficult, meaning we'd have to instead record a DF_INSN_LUID -> real-insn-luid map or real with this by effectively shortening the allowed go-back distance for re-tries (keep that farthest away insn unaltered). Still the re-starting will make the counting quite non-obvious I guess :/ (conditional on we-re before-or-after the last counted insn). Going back for each attempt sounds like doubling the walk overhead, even though it's technically O(1) with a low enough limit (still we'd have to walk an arbitrary number of debug-insns - same issue for the actual limit of course, given intermediate debug insns do not count).
