Feature request: gas .prefalign directive for body-size-dependent function alignment

[Fangrui Song]

On Mon, Mar 23, 2026 at 12:08 AM Jan Beulich <jbeulich@suse.com> wrote:
>
> On 21.03.2026 23:09, Fangrui Song wrote:
> > On Wed, Mar 11, 2026 at 6:58 PM Fangrui Song <i@maskray.me> wrote:
> >>
> >> Hi, I've filed a feature request
> >> (https://sourceware.org/bugzilla/show_bug.cgi?id=33943 ) proposing a
> >> new directive, `.prefalign`, for size-proportional function alignment.
> >> (LLVM's integrated assembler has already implemented a variant of this
> >> for the `-ffunction-sections` case, though its section
> >> sh_addralign-only semantics felt surprising to me, so I refined the
> >> design.)
> >>
> >> ## Proposed Syntax
> >>
> >>   .prefalign <pref_align>, <end_sym>, nop
> >>   .prefalign <pref_align>, <end_sym>, <fill_byte>
> >>
> >> - `pref_align`: preferred (maximum) alignment — must be a power of 2
> >> - `end_sym`: a symbol marking the end of the code body (forward reference)
> >> - Third operand: `nop` for target-appropriate variable-size NOP fill,
> >> or an integer fill byte [0, 255].
> >>   Expressions are not allowed.
> >>
> >> All three operands are required. Traditional `.align` implicitly uses
> >> NOPs in executable sections; `.prefalign` makes the fill intent
> >> explicit to avoid that ambiguity.
> >>
> >> There is a very minor code-size benefit. For example, both GCC and
> >> Clang prefer .p2align 4 for x86, which is wasteful for small
> >> functions.
> >> The assembler directive, once implemented, would be superior to GCC's
> >> -flimit-function-alignment.
> >
> > I am modifying the syntax to
> >
> > .prefalign <log2_align>, <end_sym>, <fill-byte> or nop
> >
> > per  https://sourceware.org/bugzilla/show_bug.cgi?id=33943
> >
> > E.g.
> >
> > # Align to 2**4 = 16, pad byte 0x00
> > .prefalign 4, end, 00
> >
> > # Align to 2**4 = 16, pad byte 0xcc
> > .prefalign 4, end, cc
> >
> > Then if multi-byte fills are ever needed,
> >
> > .prefalign 4, end, 0001
> > .prefalign 4, end, 00010203
>
> For these last two, how would the parser know how many bytes there are per
> padding token? Surely not number of digits in source?
>
> Jan

Intuitively, just count the number of bytes represented by the hex
pairs (xxd -p style)...

00 => 1 filler byte. The filler is 000000...
0001 => 2 filler bytes. The filler is 000100010001...
00010203 => 4 filler bytes.

The nop keyword means nop filler ("nop" is not matched by [0-9a-fA-F]+).