This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Label alignments in shorten_branches


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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]