Andrew Pinski <[email protected]> writes: > On Sat, Sep 6, 2025 at 2:09 PM Jeff Law <[email protected]> wrote: >> >> >> >> On 7/27/25 3:35 AM, Artemiy Volkov wrote: >> > From: Artemiy Volkov <[email protected]> >> > >> > Presently, the scheduler code only considers consecutive instructions >> > for macro-op fusion (see sched-deps.cc::sched_macro_fuse_insns () for >> > details). This patch introduces the new dep_fusion pass, which is >> > intended to uncover more fusion opportunities by reordering eligible >> > instructions to form fusible pairs (based solely on the value of the >> > TARGET_SCHED_MACRO_FUSION_PAIR_P hook). This is achieved by using >> > the RTL-SSA framework, and only the single-use instructions are >> > considered for the first instruction of a pair. >> > >> > Aside from reordering instructions, this pass also sets the SCHED_GROUP >> > flag for the second instruction so that following passes can implement >> > special handling of the fused pairs. For instance, RA and regrename >> > should make use of this information to preserve single-output property >> > for some of such pairs. Accordingly, in passes.def, this patch adds two >> > invocations of the new pass: just before IRA and just before regrename. >> > >> > The new pass is enabled at -O2+ and -Os. >> > >> > gcc/ChangeLog: >> > >> > * Makefile.in (OBJS): Add dep-fusion.o. >> > * common.opt (fdep-fusion): Add option. >> > * dep-fusion.cc: New pass. >> > * doc/invoke.texi: Document it. >> > * opts.cc (default_options_table): Enable it at -O2+ and -Os. >> > * passes.def: Insert two instances of dep_fusion. >> > * tree-pass.h (make_pass_dep_fusion): Declare new function. >> > >> > Suggested-by: Jeff Law <[email protected]> >> > Signed-off-by: Artemiy Volkov <[email protected]> >> I did a final bootstrap & regression test on x86_64 and pushed this to >> the trunk. > > There was a 17% compile time increase with this on PR 69609 (compiled > with -O2 -g) on aarch64 after this. > as noticed on > https://lnt.opensuse.org/db_default/v4/CPP/graph?plot.0=685.630.8 > . > I have not looked into the increase back in August yet. The one in May > (a few days ago) was turning on a RTL pass for aarch64 and already > reported to the list.
Hmm, so two rtl-ssa passes with similar % regressions. That's suspicious :) I'm guessing this is rtl-ssa's fault, rather than anything in the pass itself. I'll try to have a look soon... Richard
