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

[George Rimar via llvm-commits]

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) ?


http://reviews.llvm.org/D15779