On Sat, Nov 2, 2024 at 8:39 AM Alexandre Oliva <ol...@adacore.com> wrote: > > On Oct 30, 2024, Richard Biener <richard.guent...@gmail.com> wrote: > > > I think since you make the outer condition the short-circuiting one what's > > in > > the inner block isn't executed when it wasn't before the transform? So in > > fact you shouldn't need to process stmts in BB even? Only when the > > outer condition is now unconditional. > > Aah, I think I get what the goal is now. > > I suppose we could get away without resetting flow info, but even if > guarding conditions become stricter, resetting flow info makes sense so > that they're recomputed to reflect the guard changes.
Note they are "recomputed" whether or not we reset them here when the next VRP pass comes around. We need to reset the info for correctness reasons so passes between now and the next re-compute doesn't end up with invalid data. > But we need not worry about introducing undefined behavior in inner > blocks as long as we're making the outer condition that guards them > stricter. There's a twist there when we get a compound cond and split > it across neighbor blocks, as in patch #7/7, because then we may be > making the outer condition laxer. > > I'm testing an incremental patch that adds simple bounds to the amount > of stmt moving, and flow info resetting and UB avoiding for moved stmts, > and arranges to reset flow info and avoid UB in inner blocks when the > outer cond is relaxed. Thanks, Richard. > > -- > Alexandre Oliva, happy hacker https://FSFLA.org/blogs/lxo/ > Free Software Activist GNU Toolchain Engineer > More tolerance and less prejudice are key for inclusion and diversity > Excluding neuro-others for not behaving ""normal"" is *not* inclusive
