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

[Hans-Peter Nilsson]

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
> 
> fill_len, if omitted, defaults to 1 to make the common zero-filler
> easier to write.

Works for me, thanks!

brgds, H-P