https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120434
--- Comment #9 from Jakub Jelinek <jakub at gcc dot gnu.org> --- Created attachment 61587 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61587&action=edit gcc16-pr120434-wip.patch So, I've started playing with expansion, so that it defers most of the IL changes until after all expand_gimple_basic_block calls finish in a function, so that we can use ranger during expansion. Completely untested, but it helps e.g. with /* PR middle-end/79665 */ int foo (int x) { return x / 200; } int bar (int x) { if (x < 0) __builtin_unreachable (); return x / 200; } int baz (int x) { if (x >= 0) return x / 200; else return 24; } testcase at -O2 in baz, where it creates the same division sequence as in bar rather than in foo on x86_64. I'm afraid the ranger/gori etc. might need to be made slightly more forgiving when currently_expanding_to_rtl, e.g. there seems to be the case when expansion of GIMPLE_COND can remove one of the edges (either TRUE or FALSE) if expansion figures out the jump is in fact unconditional. Plus there can always be some bb->flags & BB_RTL basic blocks in the IL, those shouldn't be there for when there was original GIMPLE, so hopefully ranger/gori can ignore those, but we'll see. Anyway, for this PR we'll need to add further code to use pos_neg and decide based on costs.
