https://gcc.gnu.org/bugzilla/show_bug.cgi?id=125597
--- Comment #2 from Tamar Christina <tnfchris at gcc dot gnu.org> --- (In reply to Richard Biener from comment #1) > (gdb) p debug_gimple_stmt (at_stmt) > _42 = _38; > (gdb) p debug_tree (var) > <ssa_name 0x7ffff757f2c0 > type <integer_type 0x7ffff761c000 sizetype public unsigned DI > size <integer_cst 0x7ffff761e000 constant 64> > unit-size <integer_cst 0x7ffff761e018 constant 8> > align:64 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type > 0x7ffff761c000 precision:64 min <integer_cst 0x7ffff761e030 0> max > <integer_cst 0x7ffff7603700 18446744073709551615>> > > def_stmt GIMPLE_NOP > version:38> > > and we hit this from vect_do_peeling, this is likely the "later to be > initialized" niter thing we've introduced lately? > No, it's been there since GCC 16 for the early break IV itself and for ages for the masked control IV (and this was modelled after that). It's because we wanted to re-use vect_update_ivs_after_vectorizer. > 3955 LOOP_VINFO_NITERSM1 (epilogue_vinfo) > 3956 = fold_build2 (MINUS_EXPR, TREE_TYPE (epilogue_niters), > 3957 epilogue_niters, > 3958 build_one_cst (TREE_TYPE (epilogue_niters))); > > I suspect we need to resort to a more "temporarily VARYING" way here :/ > ISTR suggesting some internal function, like insert > > _38 = .VARYING (); > > it would be a NOVOPS (but not CONST/PURE) one maybe. Ok, so the suggestion is to insert a dummy value until we replace it later on just to make df analysis ignore it. Would using a ssa_default_def work here too? or do you prefer the IFN?
