<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Wed, Jan 20, 2016 at 12:23 AM, George Rimar <span dir="ltr"><<a href="mailto:grimar@accesssoftek.com" target="_blank">grimar@accesssoftek.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">grimar added a comment.<br>
<span class=""><br>
In <a href="http://reviews.llvm.org/D15779#330631" rel="noreferrer" target="_blank">http://reviews.llvm.org/D15779#330631</a>, @ruiu wrote:<br>
<br>
> 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.<br>
><br>
> 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.<br>
<br>
<br>
</span>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.<br>
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: <a href="http://reviews.llvm.org/D16201" rel="noreferrer" target="_blank">http://reviews.llvm.org/D16201</a>, <a href="http://reviews.llvm.org/D15779" rel="noreferrer" target="_blank">http://reviews.llvm.org/D15779</a>) ?</blockquote><div><br></div><div>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.</div><div><br></div><div>Overall, I think it's worth a shot.</div><div><br></div><div>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.</div></div></div></div>