On Mon, Oct 12, 2026 at 10:57 PM, Hongtao Liu <[email protected]> wrote: > On Sat Oct 3, 2026 at 7:02 AM PDT, Sarvesh Chandra wrote: > > + /* Bundle alignment replaces generic loop, jump, and label padding. */ > > + if (opts->x_ix86_bundle_align_loops > 0) > > + { > > + SET_OPTION_IF_UNSET (opts, opts_set, str_align_loops, "1"); > > + SET_OPTION_IF_UNSET (opts, opts_set, str_align_jumps, "1"); > > + SET_OPTION_IF_UNSET (opts, opts_set, str_align_labels, "1"); > > If we just set loop/jump/label align to 1, and keep align tight loops, > can we get similar code size reduction without performance drop?
We do get similar code size reduction, but not without a performance drop on znver5. I am attaching the Cauldron page here, which contains the slides referring to the impact of bundle align against tight align in isolation: https://conf.gnu-tools-cauldron.org/prg26/talk/HS9RPC/ > It sounds to me bundle alignments is an enhancement to current tightloop > alignment with dynamic decision in assembler instead of hard-coded > .palign. so what's the real gain of the new pass against the original > align_tight_loop? Bundle not only wins due to hardcoded palign, but also due to the crossing hot regions present in layout which need smarter insertion of padding. We saw the impact of this in the microbenchmarks in the Appendix section as well as the tupledealloc loop of cpython_r, which had commit-to-commit variation, fixed by bundle align which identifies the entire region in one bundle, vs tight which chooses one of them. > The pass manually setting all other alignments to 1, if the assembler > doesn't support the new directive .bundle_{lock, unlock}, do we have a > way to fallback? or just lose all alignment with some performance loss? The fallback when the assembler doesn't support flex bundles is the current default, that is, 16B loop/jump/label align + tight align, because we could not rule out the impact of any of the four flags on znver5. In the absence of bundle align, we can expect performance impacted negatively on frontend bound benchmarks. There are cases when setting loop/jump/label align to 1 also has a negative impact, in both real world benchmarks and microbenchmarks. Bundle align is one way to address all of these regressions under one umbrella. On Mon, Oct 5, 2026 at 10:08 AM, Richard Biener <[email protected]> wrote: > On Sat, Oct 3, 2026 at 4:03 PM Sarvesh Chandra wrote: > > +static void > > +bundle_compute_layout (HOST_WIDE_INT *bb_lo, HOST_WIDE_INT *bb_hi, > > + int *asm_lo, int *asm_hi) > > +{ > > + HOST_WIDE_INT off = 0; > > + int nasm = 0; > > + basic_block bb; > > + FOR_EACH_BB_FN (bb, cfun) > > can you avoid doing this for non-candidate loop blocks? We need to do this for non-candidate blocks too, as the interval [lo, hi] for a candidate may contain non-candidate blocks. But we could start counting at the first block that has a valid loop father. > > +bundle_collect_candidates (vec<bundle_cand> &feas, HOST_WIDE_INT k, > > + HOST_WIDE_INT *bb_lo, HOST_WIDE_INT *bb_hi, > > + int *asm_lo, int *asm_hi) > > +{ > > + /* Step 1: identify feasible candidates from layout-backward loop edges. > > */ > > + basic_block bb; > > + FOR_EACH_BB_FN (bb, cfun) > > I wonder if you can instead walk the loop tree? This is a layout-based optimization, trying to find hot contiguous layout regions which can fit in one bundle, so a loop-tree traversal won't identify our candidates. > > +ix86_do_bundle_align_loops () > > +{ > > + if (ix86_cost->prefetch_block == 0) > > || number_of_loops (cfun) <= 1 > > > + return; I will add this in v2, while also moving this from RFC to PATCH. Thanks Richard and Hongtao! Regards, Sarvesh
