[llvm-dev] Linux/ARM: Segfault issue when we build clang sources including __thread variable using -O2 flag

[Geunsik Lim via llvm-commits]

> r268662: we cannot combine the 2 ldr instructions and litpools because
they get added to
> a different pc to form the correct address.

I wonder that the literal pools also (as well as the two 'ldr'
instructions) are related to the incorrect merging of
the different PC-anchors in case of the global-dynamic TLS model with
aggressive optimization levels such as
O2/O3 for Linux/ARM. For example, because the -fPIC of coreCLR (e.g.
libcoreclr.so) is dependent on the litpools.


To understand litpools in more detail, is there a technical document
besides the below
"ARM Compiler armasm User Guide"? If you know, could you share me? On the
other hand,
it seems that this issue can be reproduced on the AArch64 port of LLVM.

* ARM Compiler armasm User Guide - 4.7 Literal pools:
http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0473j/dom1359731147760.html

> The actual pass doing the final transformation (loop invariant code
motion) probably doesn't run at -O0,
> but I'd expect it at all others.

After the official holiday, I am going to experiment again the .NET Core
run-time (e.g. libcoreclr.so)
with O2/O3/Os/Oz flags after applying the r268662 to the LLVM3.5  back-end
on Linux/ARM device. Thanks.



On May 6, 2016 10:58 PM, "Tim Northover" <t.p.northover at gmail.com> wrote:

> On 5 May 2016 at 23:27, Geunsik Lim <leemgs at gmail.com> wrote:
> > BTW, the above "ACPV->AddCurrentAddress == AddCurrentAddress"  statement
> > does also handle in case of other Oz/Os levels as well as O2/O3
> optimization
> > levels?
>
> Yes, this code is applied at all optimization levels (when asked). The
> actual pass doing the final transformation (loop invariant code
> motion) probably doesn't run at -O0, but I'd expect it at all others.
>
> > As I reported previously, we have not experienced a incorrect operation
> of
> > __thread variable (via __tls_get_addr symbol) with O0/O1 flags. Maybe,
> does
> > a key reason of this issue  is LLVM's inline transform pass (e.g.,
> > llvm-opt)?
>
> The inliner was needed in this case because most TLS accesses were
> hidden away in GetThread. You could write C code that would fail at
> -O1 if you tried.
>
> I'm' afraid I don't tend to pay attention to exactly which passes get
> run at different optimization levels, so can't really answer any
> detailed questions there.
>
> Cheers.
>
> Tim.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20160507/9fd13ca8/attachment.html>