Label alignments in shorten_branches

[Joern Rennecke]

Quoting Bernd Schmidt <bernds_cb1@t-online.de>:

> amylaar@spamcop.net wrote:
>> It is beneficial when more than one alignment of the same size is spanned,
>
> How so?  If the code assumes (as you said) that insn lengths are not
> accurate, can't each of these alignments contribute the maximum amount
> of padding?

If it was estimated during branch shortening to contribute the maximum amount
padding, then yes; but that's unlikely.
More common is that the estimated padding is not maximal.  And if the padding
increases due to some instructions actually being shorter, the total length
of these shortened instructions and the padding is still not increased.
I.e. if the branch goes across both the shortened instructions and the
padding, you won't see a distance increase.  Only if the decreased-length
instructions are outside of the branch span does the distance potentially
increase.
In fact, no matter how many alignments there are in any branch distance, the
maximum growth is no larger than the padding for one maximal alignment.
But such a gross estimate is not only suboptimal, but also gives unstable
instruction lengths during branch shortening.  The align_fuz mechanism,
however, will make branch shortening converge in a finite amount of iterations
if there are no other sources that could introduce oscillations.

> I guess I could do with seeing an example.

  bf 1f
  .p2align 5
  nop
  nop
  nop
  nop
  nop
  .p2align 5
1:

The first p2align could intruduce padding as large as 30 bytes.
The second one, however, is exactly 22 bytes long, since the alignment
of the block of nops is already as large as the required alignment.
If, instead of the nops, you had some instruction (sequence) that could
shrink, the padding for the second p2align could increase, but that would
not affect the branch offset.