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 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]+).

Pleeease use regular syntax, not some new special format.
Like, not:

> > > .prefalign 4, end, 0001

But instead:
 .prefalign 4, end, 2, 1
same as:
 .prefalign 4, end, 0x2, 0x1

Not:
> > > .prefalign 4, end, 00010203

But instead:
 .prefalign 4, end, 4, 0x010203
same as:
 .prefalign 4, end, 0x4, 0x00010203

...and maybe, if the last operande doesn't parse as a number, 
then try parsing it an instruction.

PS. I use .p2alignw for a conceptually similar effect in the gcc 
CRIS port to handle an errata making sure the multiply insn is 
not the last insn on a cache-line (32 bytes):

...
 .p2alignw 5,050f,2
 muls.d $r11,$r10

where 0x05 is, as you might guess, a 2-byte nop insn.

brgds, H-P