[llvm-dev] [LLD] Linker Relaxation

Rui Ueyama via llvm-dev llvm-dev at lists.llvm.org
Wed Jul 12 09:27:08 PDT 2017


On Wed, Jul 12, 2017 at 4:10 AM, Bruce Hoult <bruce at hoult.org> wrote:

> On Wed, Jul 12, 2017 at 10:26 AM, PkmX via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
>
>> Note that RISC-V also handles alignment as part of relaxation, so it
>> isn't really optional. For example:
>>
>> _start:
>>     mv      a0, a0
>>     .p2align 2
>>     li      a0, 0
>>
>> The assembler inserts a 3-byte padding (note: this behavior isn't
>> merged yet, see: https://github.com/riscv/riscv-binutils-gdb/pull/88):
>>
>> 00000000 <_start>:
>>    0:   852a                    mv      a0,a0
>>    2:   00 01 00                        # R_RISCV_ALIGN
>>                         2: R_RISCV_ALIGN        *ABS*+0x3
>>    5:   4501                    li      a0,0
>>
>> The linker then remove 1 byte from padding to align to the desired width:
>>
>
> This seems ... pessimised :-)
>
> At least output 4 bytes not 3! To keep it legal before the linker changes
> sizes.
>
> The assembler can easily keep track of the current alignment as it
> generates the code, and create an object file that is correct assuming no
> size changes by the linker.
>

Yeah, I think I strongly agree with that. Code shrinking relaxation is a
good optional optimization, but mandating it doesn't sound like a good idea.

If there is, say, a .byte literal of length one then the ".p2align 2"
> should perhaps emit 7 bytes? Then it is legal as-is if the linker doesn't
> change the size of anything, or the linker can delete as much as possible
> if it is adjusting sizes.
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170712/9db157df/attachment.html>


More information about the llvm-dev mailing list