[PATCH] D15779: [ELF] - Implemented optimization for R_X86_64_GOTPCREL relocation.

[Rafael Espíndola via llvm-commits]

Or, we should try not computing the size upfront:

// It might be possible to avoid this by outputting the file with write:
// * Write the allocated output sections, computing addresses.
// * Apply relocations, recording which ones require a dynamic reloc.
// * Write the dynamic relocations.
// * Write the rest of the file.

On 20 January 2016 at 09:39, Rafael Espíndola
<rafael.espindola at gmail.com> wrote:
> On 19 January 2016 at 18:49, Rui Ueyama <ruiu at google.com> wrote:
>> ruiu added a comment.
>>
>> This is not a comment for this particular patch, but in general, pieces of code for code relaxation are scattered to many places -- you have multiple calls of canXXX and call optimizeXXX at some place. It tend to hard to understand. Each patch doesn't increase complexity that much, but when they accumulate, they look being entangled.
>>
>> Can we separate code relaxation from relocation application? I think that we can create a function that visits all relocations and rewrite code and possibly relocations to relax code, and call that function before applying relocations. Then when we are applying relocations, we don't need to think about code relaxation at all. Anyway, I'd like to find some way to reduce complexity of relocation application.
>
> I agree. We check for relocation properties multiple times
>
> * Initial scan to find the size of the dynamic relocations.
> * Writing the dynamic relocations.
> * Applying the relocations.
>
> In the first pass we should probably be recording what we found about
> the dynamic relocation so that writing them in basically a memcpy. We
> should also remeber what optimization we decided were possible, so
> that we don't have to make the same decisions again when applying
> relocations.
>
> Cheers,
> Rafael