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

[Fangrui Song]

On Tue, Mar 24, 2026 at 5:05 PM Hans-Peter Nilsson <hp@bitrange.com> wrote:
>
> On Mon, 23 Mar 2026, Fangrui Song wrote:
> > On Mon, Mar 23, 2026 at 8:35?PM Hans-Peter Nilsson <hp@bitrange.com> wrote:
> > >
> > > On Mon, 23 Mar 2026, Fangrui Song wrote:
> > > > 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:
> > > > > > .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]+).
> >
> > I have never encountered a use case that requires the fill value to be
> > an expression
>
> My argument is for consistency of the *format* of the (literal)
> value, not about using it for an *expression*.  (For all I care,
> you could require a non-expression literal, if you prefer.)
>
> Having said that, you may have realized it but JFTR...
>
> > (just use the C preprocessor if you have such a use
> > case!), so I suggested hex pairs...
>
> ...arguing expression use cases to go through the C preprocessor
> (like, gcc applied on a .S file emitting an .s file) is an
> argument *against* requiring a non-prefixed hex number.  The C
> preprocessor doesn't evalate expressions in the output (except
> in preprocessor directives like #if), it just expands them.
> But maybe I misunderstood you.
>
> Still, as you wrote later,
>
> > > Pleeease use regular syntax, not some new special format.
> > > Like, not:
> [omitted]
>
> > But if there is a preference for len+fill_value representation, then let's use
> >
> > .perfalign <log2_align>, <end_sym>, <fill_exp> [, <fill_len>]
> > .perfalign <log2_align>, <end_sym>, nop

Sorry, there was a typo. I meant `.prefalign`.

> > fill_len, if omitted, defaults to 1 to make the common zero-filler
> > easier to write.
>
> Works for me, thanks!
>
> brgds, H-P

Thanks!

Per feedback on
https://github.com/llvm/llvm-project/pull/184032#issuecomment-4124693420
, I decided to use `.p2prefalign`.

.p2prefalign <log2_align>, <end_sym>, <fill_exp> [, <fill_len>]
.p2prefalign <log2_align>, <end_sym>, nop