[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