https://sourceware.org/bugzilla/show_bug.cgi?id=33943
Jan Beulich <jbeulich at suse dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |jbeulich at suse dot com
Severity|normal |enhancement
--- Comment #1 from Jan Beulich <jbeulich at suse dot com> ---
(In reply to Fangrui Song from comment #0)
> Compilers emit `.p2align 4` (or similar) before functions to align them to a
> preferred boundary (e.g. 16 bytes on x86-64). This is good for large
> functions but wasteful for small ones: a 3-byte function padded to a 16-byte
> boundary wastes up to 15 bytes — 500% overhead.
Hmm, for me 16 - 3 = 13.
As you're considering compilers, wouldn't such very small functions generally
best be inlined? And even if not, as that's not possible when e.g. a library
has to provide an implementation, won't compilers' size estimates for extremely
small functions generally be correct?
> .prefalign <pref_align>, <end_sym>, nop
> .prefalign <pref_align>, <end_sym>, <fill_byte>
>
> - `pref_align`: the preferred (maximum) alignment, must be a power of 2
Why not make it .p2align-like, requiring the power of 2 to be specified?
> - `end_sym`: a symbol marking the end of the code body
> - Third operand: `nop` for target-appropriate (variable-size) NOP fill, or
> an integer byte value `[0, 255]`
This looks x86-centric. The padding in code may want to be something else than
NOP, yet that can't be specified by <fill_byte> if insn size / granularity is
larger than a byte. This would need to be a fill pattern of (at least) insn
granularity size.
> To enforce a minimum alignment independently, users emit both `.p2align` and
> `.prefalign`.
I consider the need to use two directives as problematic. What if they're not
sitting back to back?
And the - how is this going to work for targets aiming at mainly link-time
relaxation (RISC-V for example)?
--
You are receiving this mail because:
You are on the CC list for the bug.
