Incorrect alignment assumption for emulated TLS on ARMv7

[goottime]

Description

The LLVM compiler generates incorrect ARM assembly code that assumes 128-bit alignment for emulated TLS variables, when only 32-bit (4-byte) alignment is guaranteed.

Reproducer

Given the following LLVM IR:

@test = internal thread_local(localdynamic) global [64 x i8] c"AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA"
declare void @llvm.memcpy.p0i8.p0i8.i32(i8* nocapture writeonly, i8* nocapture readonly, i32, i1 immarg)
define void @testfunc() {
    %1 = alloca [64 x i8], align 1
    %a = getelementptr inbounds [64 x i8], [64 x i8]* %1, i32 0, i32 0
    %b = getelementptr inbounds [64 x i8], [64 x i8]* @test, i32 0, i32 0
    call void @llvm.memcpy.p0i8.p0i8.i32(i8* %a, i8* %b, i32 64, i1 false)
    ret void
}

Compiled with: llc -O3 -emulated-tls -mtriple=armv7-linux-gnueabihf

Actual Output

testfunc:                               @ @testfunc
        push    {r11, lr}
        sub     sp, sp, #64
        movw    r0, :lower16:__emutls_v.test
        movt    r0, :upper16:__emutls_v.test
        bl      __emutls_get_address
        vld1.64 {d16, d17}, [r0:128]!
        vld1.64 {d18, d19}, [r0:128]!
        vld1.64 {d20, d21}, [r0:128]!
        vld1.64 {d22, d23}, [r0:128]
        mov     r0, sp
        vst1.64 {d16, d17}, [r0]!
        vst1.64 {d18, d19}, [r0]!
        vst1.64 {d20, d21}, [r0]!
        vst1.64 {d22, d23}, [r0]
        add     sp, sp, #64
        pop     {r11, pc}
__emutls_v.test:
        .long   64                              @ 0x40
        .long   1                               @ 0x1
        .long   0
        .long   __emutls_t.test
__emutls_t.test:
        .zero   64,65

Problem

The generated code uses vld1.64 instructions with :128 alignment specifiers, which require 128-bit (16-byte) alignment. However, emulated TLS only guarantees 4-byte alignment on ARMv7.

From the emulated TLS implementation in compiler-rt/lib/builtins/emutls.c:

static __inline void *emutls_allocate_object(__emutls_control *control) {
  size_t size = control->size;
  size_t align = control->align;
  void *base;
  if (align < sizeof(void *))
    align = sizeof(void *);  // Only guarantees pointer-size alignment (4 bytes on ARMv7)
  // ...
}

This mismatch between assumed alignment (128-bit) and actual alignment (32-bit) will cause crashes or undefined behavior at runtime.

Expected Behavior

The compiler should either:

• Use unaligned load instructions when emulated TLS is enabled, or
• Ensure emulated TLS allocations meet the alignment requirements used in the generated code

[llvmbot]

@llvm/issue-subscribers-backend-arm

Author: None (goottime)

## Description

The LLVM compiler generates incorrect ARM assembly code that assumes 128-bit alignment for emulated TLS variables, when only 32-bit (4-byte) alignment is guaranteed.

Reproducer

Given the following LLVM IR:

@<!-- -->test = internal thread_local(localdynamic) global [64 x i8] c"AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA"
declare void @<!-- -->llvm.memcpy.p0i8.p0i8.i32(i8* nocapture writeonly, i8* nocapture readonly, i32, i1 immarg)
define void @<!-- -->testfunc() {
    %1 = alloca [64 x i8], align 1
    %a = getelementptr inbounds [64 x i8], [64 x i8]* %1, i32 0, i32 0
    %b = getelementptr inbounds [64 x i8], [64 x i8]* @<!-- -->test, i32 0, i32 0
    call void @<!-- -->llvm.memcpy.p0i8.p0i8.i32(i8* %a, i8* %b, i32 64, i1 false)
    ret void
}

Compiled with: llc -O3 -emulated-tls -mtriple=armv7-linux-gnueabihf

Actual Output

testfunc:                               @ @<!-- -->testfunc
        push    {r11, lr}
        sub     sp, sp, #<!-- -->64
        movw    r0, :lower16:__emutls_v.test
        movt    r0, :upper16:__emutls_v.test
        bl      __emutls_get_address
        vld1.64 {d16, d17}, [r0:128]!
        vld1.64 {d18, d19}, [r0:128]!
        vld1.64 {d20, d21}, [r0:128]!
        vld1.64 {d22, d23}, [r0:128]
        mov     r0, sp
        vst1.64 {d16, d17}, [r0]!
        vst1.64 {d18, d19}, [r0]!
        vst1.64 {d20, d21}, [r0]!
        vst1.64 {d22, d23}, [r0]
        add     sp, sp, #<!-- -->64
        pop     {r11, pc}
__emutls_v.test:
        .long   64                              @ 0x40
        .long   1                               @ 0x1
        .long   0
        .long   __emutls_t.test
__emutls_t.test:
        .zero   64,65

Problem

The generated code uses vld1.64 instructions with :128 alignment specifiers, which require 128-bit (16-byte) alignment. However, emulated TLS only guarantees 4-byte alignment on ARMv7.

From the emulated TLS implementation in compiler-rt/lib/builtins/emutls.c:

static __inline void *emutls_allocate_object(__emutls_control *control) {
  size_t size = control->size;
  size_t align = control->align;
  void *base;
  if (align < sizeof(void *))
    align = sizeof(void *);  // Only guarantees pointer-size alignment (4 bytes on ARMv7)
  // ...
}

This mismatch between assumed alignment (128-bit) and actual alignment (32-bit) will cause crashes or undefined behavior at runtime.

Expected Behavior

The compiler should either:

• Use unaligned load instructions when emulated TLS is enabled, or
• Ensure emulated TLS allocations meet the alignment requirements used in the generated code

[efriedma-quic]

emutls supports globals with higher alignment. I think llvm/lib/CodeGen/LowerEmuTLS.cpp is just computing the alignment of the global incorrectly; it's computing lower alignment than what Value::getPointerAlignment() returns.

[efriedma-quic]

(If you explicitly mark the global "align 16", it seems like LLVM emits the right thing.)

[llvmbot]

Hi!

This issue may be a good introductory issue for people new to working on LLVM. If you would like to work on this issue, your first steps are:

1. Check that no other contributor is working on this issue. If someone is assigned to the issue or claimed to be working on it, ping the person. After one week without a response, the assignee may be changed.
2. Leave a comment indicating that you are working on the issue, or just create a pull request after following the steps below. Mention this issue in the description of the pull request.
3. Fix the issue locally.
4. Run the test suite locally. Remember that the subdirectories under test/ create fine-grained testing targets, so you can e.g. use make check-clang-ast to only run Clang's AST tests.
5. Create a Git commit.
6. Run git clang-format HEAD~1 to format your changes.
7. Open a pull request to the upstream repository on GitHub. Detailed instructions can be found in GitHub's documentation. Mention this issue in the description of the pull request.

If you have any further questions about this issue, don't hesitate to ask via a comment in the thread below.

[llvmbot]

@llvm/issue-subscribers-good-first-issue

Author: None (goottime)

## Description

The LLVM compiler generates incorrect ARM assembly code that assumes 128-bit alignment for emulated TLS variables, when only 32-bit (4-byte) alignment is guaranteed.

Reproducer

Given the following LLVM IR:

@<!-- -->test = internal thread_local(localdynamic) global [64 x i8] c"AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA"
declare void @<!-- -->llvm.memcpy.p0i8.p0i8.i32(i8* nocapture writeonly, i8* nocapture readonly, i32, i1 immarg)
define void @<!-- -->testfunc() {
    %1 = alloca [64 x i8], align 1
    %a = getelementptr inbounds [64 x i8], [64 x i8]* %1, i32 0, i32 0
    %b = getelementptr inbounds [64 x i8], [64 x i8]* @<!-- -->test, i32 0, i32 0
    call void @<!-- -->llvm.memcpy.p0i8.p0i8.i32(i8* %a, i8* %b, i32 64, i1 false)
    ret void
}

Compiled with: llc -O3 -emulated-tls -mtriple=armv7-linux-gnueabihf

Actual Output

testfunc:                               @ @<!-- -->testfunc
        push    {r11, lr}
        sub     sp, sp, #<!-- -->64
        movw    r0, :lower16:__emutls_v.test
        movt    r0, :upper16:__emutls_v.test
        bl      __emutls_get_address
        vld1.64 {d16, d17}, [r0:128]!
        vld1.64 {d18, d19}, [r0:128]!
        vld1.64 {d20, d21}, [r0:128]!
        vld1.64 {d22, d23}, [r0:128]
        mov     r0, sp
        vst1.64 {d16, d17}, [r0]!
        vst1.64 {d18, d19}, [r0]!
        vst1.64 {d20, d21}, [r0]!
        vst1.64 {d22, d23}, [r0]
        add     sp, sp, #<!-- -->64
        pop     {r11, pc}
__emutls_v.test:
        .long   64                              @ 0x40
        .long   1                               @ 0x1
        .long   0
        .long   __emutls_t.test
__emutls_t.test:
        .zero   64,65

Problem

The generated code uses vld1.64 instructions with :128 alignment specifiers, which require 128-bit (16-byte) alignment. However, emulated TLS only guarantees 4-byte alignment on ARMv7.

From the emulated TLS implementation in compiler-rt/lib/builtins/emutls.c:

static __inline void *emutls_allocate_object(__emutls_control *control) {
  size_t size = control->size;
  size_t align = control->align;
  void *base;
  if (align < sizeof(void *))
    align = sizeof(void *);  // Only guarantees pointer-size alignment (4 bytes on ARMv7)
  // ...
}

This mismatch between assumed alignment (128-bit) and actual alignment (32-bit) will cause crashes or undefined behavior at runtime.

Expected Behavior

The compiler should either:

• Use unaligned load instructions when emulated TLS is enabled, or
• Ensure emulated TLS allocations meet the alignment requirements used in the generated code

[jackhong12]

Hi @efriedma-quic,
May I try this issue?

[efriedma-quic]

Sure, go ahead; let me know if you have any questions.