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

[Jan Beulich]

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