gas .align limit

[Richard Earnshaw (lists)]

On 17/05/2025 11:14, Alan Modra wrote:
> I've been looking at removing any requirement that rs_align_code
> frags need lots of memory.  They should not, because the patterns of
> nops used always have repeating sequences, and the repeating part only
> needs memory for one repeat.  The attached patch cleans up all the
> target HANDLE_ALIGN code, except for x86_64.  I've left x86 because
> I'm unsure whether it matters that the short nop sequence is last.  If
> it doesn't matter then it can be placed first, and the repeating part
> handled as for all other targets.  If it should remain last then it
> needs to be moved to a separate frag as is done for the group ending
> nop on ppc.
> 
> cc'ing kvx and arm maintainers, because those targets have the most
> significant changes and probably ought to be scrutinized well.
> 

As usual, Arm is just complicated...

We have 2 ISAs: Arm and Thumb

We have legacy CPUs with no architecturally defined NOPs

and in Thumb2 variants we have 16-bit and 32-bit NOPs.

Ideally, when padding with NOPs on thumb we should try to use 32-bit NOPs, since they take less time to execute (fewer instructions).  But we should also try to align 32-bit nops to 32-bit boundaries if it's not unreasonable; that might mean putting a 16-bit nop out first, then filling the rest of the space with 32-bit nops, or I guess it could mean doing the reverse (though that's unlikely with padding for alignment, unless you have some special case supported like N-bytes beyond this alignment).  Even then, it might be easier faster to do N 32-bit nops that are not aligned than to top-and-tail with 16-bit nops.

Some sort of general structure for padding would likely then need to contain details of preamble, body, tail such that we can pick appropriately from that once we know the final amount of padding to insert.  We should be able to tell at the time we parse the align directive which values to use for each field, since it will match the current ISA.

R.