<div dir="ltr"><p dir="ltr">> r268662: we cannot combine the 2 ldr instructions and litpools because they get added to <br>> a different pc to form the correct address.<br></p><p dir="ltr">I wonder that the literal pools also (as well as the two 'ldr' instructions) are related to the incorrect merging of <br>the different PC-anchors in case of the global-dynamic TLS model with aggressive optimization levels such as <br>O2/O3 for Linux/ARM. For example, because the -fPIC of coreCLR (e.g. libcoreclr.so) is dependent on the litpools.</p><p dir="ltr"><br>To understand litpools in more detail, is there a technical document besides the below <br>"ARM Compiler armasm User Guide"? If you know, could you share me? On the other hand, <br>it seems that this issue can be reproduced on the AArch64 port of LLVM.</p><p dir="ltr">* ARM Compiler armasm User Guide - 4.7 Literal pools:<a href="http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0473j/dom1359731147760.html">http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0473j/dom1359731147760.html</a></p><p dir="ltr">> The actual pass doing the final transformation (loop invariant code motion) probably doesn't run at -O0, <br>> but I'd expect it at all others.</p><p dir="ltr">After the official holiday, I am going to experiment again the .NET Core run-time (e.g. libcoreclr.so)  <br>with O2/O3/Os/Oz flags after applying the r268662 to the LLVM3.5  back-end on Linux/ARM device. Thanks.<br></p><p dir="ltr"><br></p><p dir="ltr"><br></p>
<div class="gmail_quote">On May 6, 2016 10:58 PM, "Tim Northover" <<a href="mailto:t.p.northover@gmail.com" target="_blank">t.p.northover@gmail.com</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">On 5 May 2016 at 23:27, Geunsik Lim <<a href="mailto:leemgs@gmail.com" target="_blank">leemgs@gmail.com</a>> wrote:<br>
> BTW, the above "ACPV->AddCurrentAddress == AddCurrentAddress"  statement<br>
> does also handle in case of other Oz/Os levels as well as O2/O3 optimization<br>
> levels?<br>
<br>
Yes, this code is applied at all optimization levels (when asked). The<br>
actual pass doing the final transformation (loop invariant code<br>
motion) probably doesn't run at -O0, but I'd expect it at all others.<br>
<br>
> As I reported previously, we have not experienced a incorrect operation of<br>
> __thread variable (via __tls_get_addr symbol) with O0/O1 flags. Maybe, does<br>
> a key reason of this issue  is LLVM's inline transform pass (e.g.,<br>
> llvm-opt)?<br>
<br>
The inliner was needed in this case because most TLS accesses were<br>
hidden away in GetThread. You could write C code that would fail at<br>
-O1 if you tried.<br>
<br>
I'm' afraid I don't tend to pay attention to exactly which passes get<br>
run at different optimization levels, so can't really answer any<br>
detailed questions there.<br>
<br>
Cheers.<br>
<br>
Tim.<br>
</blockquote></div>
</div>