[llvm-bugs] [Bug 37061] New: Global -> Constant promotion for atomics fails on platforms using intrinsics

[via llvm-bugs]

https://bugs.llvm.org/show_bug.cgi?id=37061

            Bug ID: 37061
           Summary: Global -> Constant promotion for atomics fails on
                    platforms using intrinsics
           Product: libraries
           Version: trunk
          Hardware: PC
                OS: Windows NT
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: Scalar Optimizations
          Assignee: unassignedbugs at nondot.org
          Reporter: alex at crichton.co
                CC: llvm-bugs at lists.llvm.org

First discovered in https://github.com/rust-lang/rust/issues/49775 we've found
that LLVM will promote unmodified `global` definitions to `constant` through
the optimization passes. On some platforms, however, these constants may
actually be modified causing the promotion to cause a page fault at runtime
(modifying readonly memory).

The specific case we ran into was that on our Android configuration we've got
enough flags that disable atomic instruction generation and instead lowers down
to usage of the libgcc intrinsics for atomics. Namely we have a module like:



@FOO = internal unnamed_addr global <{ [4 x i8] }> zeroinitializer, align 4

define void @main() {
  %a = load atomic i32, i32* bitcast (<{ [4 x i8] }>* @FOO to i32*) seq_cst,
align 4
  ret void
}



Where when this is optimized with `/opt foo.ll -mtriple=arm-linux-androideabi
-mattr=+v5te,+strict-align -o - -S -O2` it will generate:


@FOO = internal unnamed_addr constant <{ [4 x i8] }> zeroinitializer, align 4


The assembly, however, generates:


main:

        .type   FOO,%object             @ @FOO
        .section        .rodata.cst4,"aM",%progbits,4
        .p2align        2
FOO:
        .zero   4
.size FOO, 4


Albeit my assembly isn't super strong but `nm` confirms that `FOO` is indeed in
rodata rather than in bss like it originally would be. Unfortunately though the
assembly also makes use of __sync_val_compare_and_swap_4, an intrinsic in
libgcc. The intrinsic dispatches to __kuser_cmpxchg it looks like.

In our tests where we run inside the Android emulator it looks like the kernel
detects that the local "hardware" actually has atomic instructions so
__kuser_cmpxchg uses `ldrex` and `strexeq`. The `strexeq` instruction, however,
caues a page fault as it can't store the value back into `.rodata`

Some more information is at the end of the referenced issue at
https://github.com/rust-lang/rust/issues/49775#issuecomment-379851925 but I was
wondering, is this something that we should be disabling locally? Or is this an
LLVM misoptimization?

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20180409/ad99d344/attachment.html>