On Oct 22, 2024, Richard Biener <richard.guent...@gmail.com> wrote: > On Mon, Oct 21, 2024 at 4:30 AM Alexandre Oliva <ol...@adacore.com> wrote: >> >> On Oct 10, 2024, Richard Biener <richard.guent...@gmail.com> wrote: >> >> > As you special-case hard register uses, do we want to ever make >> > hard-register >> > uses or defs unconditional? I'll note that on GIMPLE hard register >> > uses/defs >> > are treated as memory, so they have virtual defs and uses. >> >> Erhm, do I? I don't recall that, and I can't tell what you're getting >> at.
> Somewhere you tested DECL_HARD_REGISTER? Aah, yeah, that was in ssa_is_substitutable_p, mostly copied from ssa_is_replaceable_p. > I'll note that you do the transforms "greedily" rather than re-constructing > a combined condition from the CFG and find the "global" best combinations. *nod* For the intended case, namely combining bitfield compares whose bits are loaded from the same "word", this greedy approach is fine: the combinations accumulate until all combinable tests involving the same "words" become one. For other circumstances, I can see that smarter algorithms might be called for. > Being able > to identify the CFG part that can be freely associated (no side-effects > intervening) this way is a first step thats somehow hidden in your patch. *nod* Hopefully it will be more clearly visible in the upcoming patchset. > I see. Maybe we want to put some hard limit on the amount of work the > pass does trying to form combinations. I`ve dropped the retrying ifcombining preds, and instead made the loop that searches for an outer node to ifcombine with inner run all the way. I suppose we could add a param to limit that, but exploring all pairs of conditions in a straight-line region whose conditionals all share the same exit doesn't strike me as particularly expensive. It's theoretically O(n^2) on the block count, where the previous constraint on combining neighbor blocks was O(n), but the constraints of no side effects and on the shape of the region seem to make this not much of an issue. -- 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
