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

[Rui Ueyama via llvm-commits]

On Wed, Jan 20, 2016 at 12:23 AM, George Rimar <grimar at accesssoftek.com>
wrote:

> grimar added a comment.
>
> In http://reviews.llvm.org/D15779#330631, @ruiu wrote:
>
> > 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 need to think about how possible to do that better. In general that
> looks for me like additional pass through all relocations and marking them
> or excluding from futher pass. Idea itself looks attractive for me, but I
> afraid of possible code duplication that might happen in that case.
> Also do you mean you want to see that change before landing any other
> relaxation patch or its fine to make it right after current pending ones
> (there are two of them from my side now at reviews:
> http://reviews.llvm.org/D16201, http://reviews.llvm.org/D15779) ?


Currently relocations are applied and optimized in a single pass. It would
be great if we can split it into two passes, assuming that (1) there's not
much code duplication between the two passes, and (2) that doesn't increase
link time that much. I believe (1) is not really a concern because the
first pass focuses only on code relaxation and the second on relocation
application, so their work doesn't overlap, therefore there should not be
that much code duplication. As to (2), I'd expect that the performance
impact would be fairly small from my experience to write markLive()
function which visits all relocations.

Overall, I think it's worth a shot.

I don't like to see many more code relaxations because it makes code
refactoring harder. Fortunately, code relaxation is an optional
optimization, so you don't have to do that, so we can suspend that for now.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20160120/d6d48efc/attachment.html>