<div dir="ltr">I don't think this would slow down the relocation process because the number of function calls will be the same. A quick performance test would be appreciated, though.</div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Aug 17, 2016 at 6:28 PM, Sean Silva <span dir="ltr"><<a href="mailto:chisophugis@gmail.com" target="_blank">chisophugis@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">silvas added a comment.<br>
<span class=""><br>
In <a href="https://reviews.llvm.org/D23565#518608" rel="noreferrer" target="_blank">https://reviews.llvm.org/<wbr>D23565#518608</a>, @ruiu wrote:<br>
<br>
> Eugene,<br>
><br>
> Thank you for your description. I agree that the order we compute offset is the cause of the problem. In scanRelocs, we compute a symbol offset for each symbol and assign it to a local variable `Offset` -- but that value may change if linker scripts are in use. That value is computed too early, and we want to do it lazily.<br>
><br>
> As to this patch, I'd refactor instead of applying a quick fix. It doesn't seem hard to do. For `C.Relocations` in `scanRelocs`, we are able to not store `Offset` to them because it can be computed from `Body`.<br>
<br>
<br>
</span>This makes sense, but it may have performance implications to get the offset later (at least more pointer chasing for data that we already had in cache in scanRelocs); it will need to be measured to make sure that we implement it without costing too much performance.<br>
<br>
<br>
<a href="https://reviews.llvm.org/D23565" rel="noreferrer" target="_blank">https://reviews.llvm.org/<wbr>D23565</a><br>
<br>
<br>
<br>
</blockquote></div><br></div>