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

[Jan Beulich]

On 23.03.2026 08:53, 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:
>>>>
>>>> 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?
> 
> 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.

I.e. you suggest digit counting when I indicated that's not a viable option.
That argument really ought to be permitted to be an expression. On the
expression result, how would you know how many bytes are needed?

Jan