Rust: LLVM이 더 이상 잘못 컴파일하지 않으면 기본적으로 noalias 주석을 다시 활성화합니다.

나는 여전히 근본적인 문제를 파악하기 위해 노력하고 있습니다. 흥미로운 티켓은 https://github.com/rust-lang/rust/issues/54462입니다.

@nagisa 의 최소 ​​재생산 사용:

fn linidx(row: usize, col: usize) -> usize {
    row * 1 + col * 3
}

fn swappy() -> [f32; 12] {
    let mut mat = [1.0f32, 5.0, 9.0, 2.0, 6.0, 10.0, 3.0, 7.0, 11.0, 4.0, 8.0, 12.0];

    for i in 0..2 {
        for j in i+1..3 {
            if mat[linidx(j, 3)] > mat[linidx(i, 3)] {
                    for k in 0..4 {
                            let (x, rest) = mat.split_at_mut(linidx(i, k) + 1);
                            let a = x.last_mut().unwrap();
                            let b = rest.get_mut(linidx(j, k) - linidx(i, k) - 1).unwrap();
                            ::std::mem::swap(a, b);
                    }
            }
        }
    }

    mat
}

fn main() {
    let mat = swappy();
    assert_eq!([9.0, 5.0, 1.0, 10.0, 6.0, 2.0, 11.0, 7.0, 3.0, 12.0, 8.0, 4.0], mat);
}

LLVM의 최적화 패스를 이등분하여 오류를 일으키는 패스를 찾을 수 있었습니다.

이 명령을 실행하면 실행 가능한 파일이 생성됩니다( bug.rs 를 재생산을 저장한 파일 이름으로 대체).

rustc -Z no-parallel-llvm -C codegen-units=1 -O -Z mutable-noalias=yes -C llvm-args=-opt-bisect-limit=2260 bug.rs

이 명령을 실행하는 동안 실행 파일이 손상됩니다(`assert_eq`` 실패).

rustc -Z no-parallel-llvm -C codegen-units=1 -O -Z mutable-noalias=yes -C llvm-args=-opt-bisect-limit=2261 bug.rs

LLVM 이등분 출력

이 파일의 경우, 최적화 2261 에 해당하는 Global Value Numbering on function (_ZN3bug6swappy17hdcc51d0e284ea38bE)

LLVM 개정을 이등분하면(llvmlab bisect 사용) r305936-r305938(아마도 r305938)로 좁힙니다.

[BasicAA] 대체를 위해 PartialAlias ​​대신 MayAlias를 사용합니다.

이것은 2017년 6월부터 꽤 오래된 변경 사항입니다.

편집: 커밋 설명을 보면 버그가 그 이전에 존재했을 가능성이 있지만 BasicAA에 의해 마스킹되어 이후 별칭 패스가 실행되지 않아 커밋이 수정되었습니다. 이 경우에는 컴파일러가 동일한 기본 주소를 가지고 있지만 오프셋을 알지 못하는 getelementptr 명령어 쌍 간의 앨리어싱을 확인하는 것이 포함됩니다.

Edit2: 또한 -enable-scoped-noalias=false 를 LLVM 옵션으로 전달하면 잘못된 컴파일을 방지할 수 있습니다. (이것은 noalias 처리를 완전히 비활성화하므로 놀라운 일이 아니지만 도움이되는 경우를 대비하여 ...)

GVN 이전 IR을 살펴보면 LLVM 앨리어싱 주석이 작동하는 방식에 대한 나의 이해가 올바른지 여부에 따라 여기의 근본 원인이 루프 해제에 있다고 생각합니다.

다음과 같은 코드를 고려하십시오.

int *a, *b;
for (int i = 0; i < 4; i++) {
    a[i & 1] = b[i & 1];
}

여기서 a[i & 1] 및 b[i & 1] 는 단일 반복 내에서 별칭을 지정하지 않지만 a 및 b 는 일반적으로 별칭을 지정할 수 있습니다.

LLVM IR에서는 다음과 같이 됩니다.

define void @test(i32* %addr1, i32* %addr2) {
start:
    br label %body

body:
    %i = phi i32 [ 0, %start ], [ %i2, %body ]
    %j = and i32 %i, 1
    %addr1i = getelementptr inbounds i32, i32* %addr1, i32 %j
    %addr2i = getelementptr inbounds i32, i32* %addr2, i32 %j

    %x = load i32, i32* %addr1i, !alias.scope !2
    store i32 %x, i32* %addr2i, !noalias !2

    %i2 = add i32 %i, 1
    %cmp = icmp slt i32 %i2, 4
    br i1 %cmp, label %body, label %end

end:
    ret void
}

!0 = !{!0}
!1 = !{!1, !0}
!2 = !{!1}

-loop-unroll 통해 이것을 실행하면 다음을 얻습니다.

define void @test(i32* %addr1, i32* %addr2) {
start:
  br label %body

body:                                             ; preds = %start
  %x = load i32, i32* %addr1, !alias.scope !0
  store i32 %x, i32* %addr2, !noalias !0
  %addr1i.1 = getelementptr inbounds i32, i32* %addr1, i32 1
  %addr2i.1 = getelementptr inbounds i32, i32* %addr2, i32 1
  %x.1 = load i32, i32* %addr1i.1, !alias.scope !0
  store i32 %x.1, i32* %addr2i.1, !noalias !0
  %x.2 = load i32, i32* %addr1, !alias.scope !0
  store i32 %x.2, i32* %addr2, !noalias !0
  %addr1i.3 = getelementptr inbounds i32, i32* %addr1, i32 1
  %addr2i.3 = getelementptr inbounds i32, i32* %addr2, i32 1
  %x.3 = load i32, i32* %addr1i.3, !alias.scope !0
  store i32 %x.3, i32* %addr2i.3, !noalias !0
  ret void
}

!0 = !{!1}
!1 = distinct !{!1, !2}
!2 = distinct !{!2}

루프의 4개 사본 모두가 동일한 앨리어싱 도메인에서 앨리어싱 메타데이터를 사용하는 방법에 유의하십시오. 단일 반복 내에서 noalias가 되는 대신 전체 기능에 걸쳐 noalias입니다.

마지막으로 -scoped-noalias -gvn 는 다음을 제공합니다.

define void @test(i32* %addr1, i32* %addr2) {
start:
  %x = load i32, i32* %addr1, !alias.scope !0
  store i32 %x, i32* %addr2, !noalias !0
  %addr1i.1 = getelementptr inbounds i32, i32* %addr1, i32 1
  %addr2i.1 = getelementptr inbounds i32, i32* %addr2, i32 1
  %x.1 = load i32, i32* %addr1i.1, !alias.scope !0
  store i32 %x.1, i32* %addr2i.1, !noalias !0
  store i32 %x, i32* %addr2, !noalias !0
  store i32 %x.1, i32* %addr2i.1, !noalias !0
  ret void
}

!0 = !{!1}
!1 = distinct !{!1, !2}
!2 = distinct !{!2}

a = b + 1 경우 잘못된 결과가 발생합니다.

다음 코드를 사용하여 C에서 이 문제를 재현할 수 있습니다.

#include "stdio.h"

void copy(int * restrict to, int * restrict from) {
    *to = *from;
}

void test(int *a, int *b) {
    for (int i = 0; i < 4; i++) {
        copy(&b[i & 1], &a[i & 1]);
    }
}

int main() {
    int ary[] = {0, 1, 2};
    test(&ary[1], &ary[0]);
    printf("%d %d %d\n", ary[0], ary[1], ary[2]);
    return 1;
}

Clang 6.0에서는 2 2 2 at -O0 및 1 2 2 at -O3 됩니다. 이 코드가 C의 restrict 의미 체계에서 합법적인지 확실하지 않지만 LLVM의 더 엄격한 noalias 의미 체계에서는 합법적이어야 한다고 생각합니다.

간단한 C 테스트 케이스로 축소했습니다(-O3 및 -O0에서 컴파일하고 출력 비교).

#include <stdlib.h>
#include <stdio.h>
#include <assert.h>

__attribute__((always_inline))
static inline void copy(int *restrict a, int *restrict b) {
    assert(a != b);
    *b = *a;
    *a = 7;
}

__attribute__((noinline))
void floppy(int mat[static 2], size_t idxs[static 3]) {
    for (int i = 0; i < 3; i++) {
        copy(&mat[i%2], &mat[idxs[i]]);
    }
}

int main() {
    int mat[3] = {10, 20};
    size_t idxs[3] = {1, 0, 1};
    floppy(mat, idxs);
    printf("%d %d\n", mat[0], mat[1]);
}

참고 제거하면 것을 restrict 의 동등한 C noalias , 동작은 올바른 것입니다. 그럼에도 불구하고 assert(a != b) 가 통과하여 restrict 로 호출하여 UB가 발생할 수 없음을 증명합니다.

무슨 일이 일어나고 있는지 :

1. copy()가 인라인되어 다음과 같은 결과가 나타납니다.

for (int i = 0; i < 3; i++) {
    mat[idxs[i]] = mat[i%2]; mat[i%2] = 7;
}

1. LLVM은 루프를 풉니다.

mat[idxs[0]] = mat[0]; mat[0] = 7; /* from copy(&mat[0%2], &mat[idxs[0]]) */
mat[idxs[1]] = mat[1]; mat[1] = 7; /* from copy(&mat[1%2], &mat[idxs[1]]) */
mat[idxs[2]] = mat[0]; mat[0] = 7; /* from copy(&mat[2%2], &mat[idxs[2]]) */

1. LLVM은 mat[0] 가 mat[idxs[1]] 또는 mat[1] 와 별칭을 지정할 수 없다고 생각하므로 mat[0] = 7; 와 mat[idxs[2]] = mat[0]; 사이에서 변경할 수 없으므로 안전합니다. 후자를 mat[idxs[2]] = 7; 로 최적화하기 위한 전역 값 번호 매기기 .

하지만 mat[0] 는 mat[idxs[1]] 별칭을 사용합니다. 왜냐하면 idxs[1] == 0 이기 때문입니다. 그리고 &mat[idxs[1]] 가 copy 전달되는 두 번째 반복에서 다른 인수가 &mat[1] 이기 때문에 그렇게 하지 않을 것이라고 약속하지 않았습니다. 그렇다면 왜 LLVM은 그렇게 할 수 없다고 생각합니까?

글쎄, 그것은 copy 가 인라인되는 방식과 관련이 있습니다. noalias 함수 속성은 다음과 같이 로드 및 저장 지침에서 !alias.scope 및 !noalias 메타데이터로 바뀝니다.

  %8 = load i32, i32* %0, align 4, !tbaa !8, !alias.scope !10, !noalias !13
  store i32 %8, i32* %7, align 4, !tbaa !8, !alias.scope !13, !noalias !10
  store i32 7, i32* %0, align 4, !tbaa !8, !alias.scope !10, !noalias !13

일반적으로 함수가 여러 번 인라인되는 경우 각 복사본은 alias.scope 및 noalias에 대해 고유한 ID를 가져오며, 이는 각 호출이 noalias ( restrict at C level), 이는 각 호출에 대해 다른 값을 가질 수 있습니다.

그러나 이 경우 먼저 함수가 루프에 인라인된 다음 루프가 해제될 때 인라인된 코드가 복제되며 이 중복으로 ID가 변경되지 않습니다. 이것 때문에, LLVM은 전혀 생각하지 a '의 어떤과의 캔 별칭을 b , 거짓의,'때문에 a 첫 번째와 세 번째 통화 별명에서 두 번째 호출에서 b 를 사용합니다(모두 &mat[0] 가리킴).

놀랍게도 GCC는 다른 출력으로 이것을 잘못 컴파일합니다. (-O0의 clang과 GCC는 모두 7 10 출력합니다. ; clang at -O3은 7 7 출력하고, -O3의 GCC는 10 7 출력합니다.) 어, 정말 그랬으면 좋겠습니다. 뭔가를 망치고 결국 UB를 추가하지만 방법을 모르겠습니다 ...

* 그것보다 조금 더 복잡하지만 이 경우 copy 는 포인터 산술을 사용하지 않고 두 포인터에 모두 쓰기 때문에 a != b 가 아닌 호출에 대해 부등식

헉 , 같은 설명을 찾기 위해

정말 좋은 타이밍이네요 ^^ 거의 같은 축소 테스트 케이스로 같은 결론에 도달했습니다 :)

의 라인을 따라 아마도 뭔가이 문제를 해결하려면 https://github.com/llvm-mirror/llvm/blob/54d4881c352796b18bfe7314662a294754e3a752/lib/Transforms/Utils/InlineFunction.cpp#L801은 또한 LoopUnrollPass으로 수행 할 필요가있다.

이 문제에 대한 LLVM 버그 보고서를 https://bugs.llvm.org/show_bug.cgi?id=39282 에서 제출했습니다

그리고 – 완전성을 위해 이것을 언급한 것 – 내 C 테스트 케이스를 잘못 컴파일했기 때문에 GCC에 버그 보고서를 제출했습니다. https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87609

분류: 이 내용을 올바르게 읽고 있다면 LLVM 수정 사항이 승인된 것입니다(https://reviews.llvm.org/D9375). 실제로 LLVM으로 병합하는 것이 무엇을 의미하는지, 또는 언제 그런 일이 발생했는지 잘 모르겠습니다. LLVM의 개정 프로세스에 대해 더 잘 알고 있는 사람이 문제가 현재 수정되었는지(그리고 어떤 버전에 대해) 확인해야 합니다.

병합되지 않았고 검토 프로세스가 약간 이상했고 승인한 사람은 더 이상 패치를 검토하지 않습니다.

https://reviews.llvm.org/D68484

"전체 제한" 패치 세트 로 테스트하라는 요청 이 있었습니다. 누군가가 이 패치 세트가 적용된 llvm 위에 Rust에서 noalias를 다시 활성화하려고 시도한다면 아마도 가치가 있을 것입니다.

기꺼이 그렇게 하려고 합니다.
적당히 강력한 서버(48 HT 코어, 128G 램)에 액세스할 수 있으며 패치로 모든 것을 올바르게 구축할 수 있다고 생각합니다.
작동하는 도구 모음이 있으면 어떤 상자를 사용해 보라고 권하시겠습니까?

llvm의 업스트림 마스터 에서 모든 Rust 관련 커밋 을 병합한 다음 패치 를 적용했습니다.
결과 분기는 다음과 같습니다. https://github.com/PaulGrandperrin/llvm-project/tree/llvm-master-with-rustlang-patches-and-D69542
이제 도구 모음을 컴파일하고 시도해 보겠습니다.

먼저 Rust가 실제로 noalias를 내보내도록 https://github.com/rust-lang/rust/pull/54639로 되돌려야 합니다.

가장 먼저 시도할 좋은 것은 다음과 같습니다.

pub fn adds(a: &mut i32, b: &mut i32) {
    *a += *b;
    *a += *b;
}

다음과 같이 컴파일되는지 확인합니다.

example::adds:
        mov     eax, dword ptr [rsi]
        add     eax, eax
        add     dword ptr [rdi], eax
        ret

그리고 아니

example::adds:
        mov     eax, dword ptr [rdi]
        add     eax, dword ptr [rsi]
        mov     dword ptr [rdi], eax
        add     eax, dword ptr [rsi]
        mov     dword ptr [rdi], eax
        ret

다음으로 https://github.com/rust-lang/rust/issues/54462#issue -362850708의 코드가 더 이상 잘못 컴파일되지 않는지 확인합니다.

# 54639는 않습니다 @jrmuizel주의 의 '최소한의 재생 장치 @nagisa을 포함하는 새로운 컴파일러 시험과 # 54462에 대한합니다. 전체 되돌리기가 순서대로 되지 않을 수 있습니까?

AFAIK는 일부 기본 플래그( -Zmutable-noalias=yes 로 재정의할 수 있음)를 변경하는 것에 관한 것이고 언급된 테스트 파일을 수동으로 컴파일할 수 있기 때문에 포함 여부가 중요하지 않다고 생각합니다.

아시다시피, 저는 여전히 LLVM을 빌드하려고 시도하고 있지만 지금은 Rust 관련 패치가 적용되거나 적용되지 않은 컴파일 오류가 발생합니다(예: 업스트림의 llvm 마스터 + 패치도 실패).

In file included from /usr/include/c++/8/cmath:45,
                 from /opt/rust/src/llvm-project/llvm/include/llvm-c/DataTypes.h:28,
                 from /opt/rust/src/llvm-project/llvm/include/llvm/Support/DataTypes.h:16,
                 from /opt/rust/src/llvm-project/llvm/include/llvm/ADT/Hashing.h:47,
                 from /opt/rust/src/llvm-project/llvm/include/llvm/ADT/ArrayRef.h:12,
                 from /opt/rust/src/llvm-project/llvm/include/llvm/Transforms/Utils/NoAliasUtils.h:16,
                 from /opt/rust/src/llvm-project/llvm/lib/Transforms/Utils/NoAliasUtils.cpp:13:
/opt/rust/src/llvm-project/llvm/lib/Transforms/Utils/NoAliasUtils.cpp: In function ‘void llvm::cloneNoAliasScopes(llvm::ArrayRef<llvm::MetadataAsValue*>, llvm::DenseMap<llvm::MDN
ode*, llvm::MDNode*>&, llvm::DenseMap<llvm::MetadataAsValue*, llvm::MetadataAsValue*>&, llvm::StringRef, llvm::LLVMContext&)’:
/opt/rust/src/llvm-project/llvm/lib/Transforms/Utils/NoAliasUtils.cpp:174:30: error: no matching function for call to ‘llvm::AliasScopeNode::AliasScopeNode(double)’
         llvm::AliasScopeNode SNAN(MD);
                              ^~~~
In file included from /opt/rust/src/llvm-project/llvm/include/llvm/IR/TrackingMDRef.h:16,
                 from /opt/rust/src/llvm-project/llvm/include/llvm/IR/DebugLoc.h:17,
                 from /opt/rust/src/llvm-project/llvm/include/llvm/IR/Instruction.h:21,
                 from /opt/rust/src/llvm-project/llvm/include/llvm/IR/BasicBlock.h:22,
                 from /opt/rust/src/llvm-project/llvm/include/llvm/IR/Instructions.h:27,
                 from /opt/rust/src/llvm-project/llvm/include/llvm/Transforms/Utils/NoAliasUtils.h:22,
                 from /opt/rust/src/llvm-project/llvm/lib/Transforms/Utils/NoAliasUtils.cpp:13:
/opt/rust/src/llvm-project/llvm/include/llvm/IR/Metadata.h:1446:12: note: candidate: ‘llvm::AliasScopeNode::AliasScopeNode(const llvm::MDNode*)’
   explicit AliasScopeNode(const MDNode *N) : Node(N) {}
            ^~~~~~~~~~~~~~
/opt/rust/src/llvm-project/llvm/include/llvm/IR/Metadata.h:1446:12: note:   no known conversion for argument 1 from ‘double’ to ‘const llvm::MDNode*’
/opt/rust/src/llvm-project/llvm/include/llvm/IR/Metadata.h:1445:3: note: candidate: ‘constexpr llvm::AliasScopeNode::AliasScopeNode()’
   AliasScopeNode() = default;
   ^~~~~~~~~~~~~~
/opt/rust/src/llvm-project/llvm/include/llvm/IR/Metadata.h:1445:3: note:   candidate expects 0 arguments, 1 provided
/opt/rust/src/llvm-project/llvm/include/llvm/IR/Metadata.h:1441:7: note: candidate: ‘constexpr llvm::AliasScopeNode::AliasScopeNode(const llvm::AliasScopeNode&)’
 class AliasScopeNode {
       ^~~~~~~~~~~~~~
/opt/rust/src/llvm-project/llvm/include/llvm/IR/Metadata.h:1441:7: note:   no known conversion for argument 1 from ‘double’ to ‘const llvm::AliasScopeNode&’
/opt/rust/src/llvm-project/llvm/include/llvm/IR/Metadata.h:1441:7: note: candidate: ‘constexpr llvm::AliasScopeNode::AliasScopeNode(llvm::AliasScopeNode&&)’
/opt/rust/src/llvm-project/llvm/include/llvm/IR/Metadata.h:1441:7: note:   no known conversion for argument 1 from ‘double’ to ‘llvm::AliasScopeNode&&’
/opt/rust/src/llvm-project/llvm/lib/Transforms/Utils/NoAliasUtils.cpp:177:31: error: request for member ‘getName’ in ‘__builtin_nans(((const char*)""))’, which is of non-class ty
pe ‘double’
         auto ScopeName = SNAN.getName();
                               ^~~~~~~
/opt/rust/src/llvm-project/llvm/lib/Transforms/Utils/NoAliasUtils.cpp:187:39: error: request for member ‘getDomain’ in ‘__builtin_nans(((const char*)""))’, which is of non-class
type ‘double’
             const_cast<MDNode *>(SNAN.getDomain()), Name);
                                       ^~~~~~~~~
[ 75%] Building CXX object lib/Target/Hexagon/CMakeFiles/LLVMHexagonCodeGen.dir/RDFCopy.cpp.o
make[2]: *** [lib/Transforms/Utils/CMakeFiles/LLVMTransformUtils.dir/build.make:635: lib/Transforms/Utils/CMakeFiles/LLVMTransformUtils.dir/NoAliasUtils.cpp.o] Error 1
make[2]: *** Waiting for unfinished jobs....

LLVM 마스터가 이미 패치와 동기화되지 않았고(패치의 크기와 LLVM 마스터가 이동하는 속도를 고려할 때 발생할 수 있음) LLVM 마스터의 이전 버전에 대해 빌드해야 합니까? 이에 대해 패치 작성자에게 핑을 보내는 것이 좋습니다.

그것이 바로 내가 하고 있는 일이며, 패치로 빌드되는 이전 버전을 찾으려고 노력하고 있습니다 :-)

나는 이제 문제가 llvm/master가 아니라 패치에 있다고 확신합니다.
여전히 패치와 호환되는 llvm/master의 가장 오래된 커밋은 https://github.com/llvm/llvm-project/commit/5b99c189b3bfc0faa157f7ca39652c0bb8c315a7 이지만 그 멀리까지 패치가 컴파일되지 않습니다.
나는 지금 C++를 이해하려고 하기에는 너무 피곤하고 게으르다. 나는 내일 다시 시도할 것이다.
그 동안 누군가가 패치 작성자에게 연락하여 도움을 요청할 수 있습니까?

Rustllvm 을 패치하지 않고 (실제로 빌드한 후) Rust와 함께 마스터 LLVM을 쉽게 사용할 수 있을 것이라고 생각하지 않습니다. AFAIK는 현재 릴리스 6-9만 지원합니다.

@mati865 먼저 러스트의 llvm-9 포크에 패치를 적용해 보았지만 역시 만만치 않았습니다...

패치는 분명히 llvm/ llvm-project@82d3ba87d06f9e2abc6e27d8799587d433c56630의 상단에 기반을

@jrmuize 감사합니다 시도해보겠습니다!
그 동안 llvm master로 빌드하도록 rustllvm 을 성공적으로 적용할 수 있었습니다.

@PaulGrandperrin 에 핑, 업데이트가 있습니까?

https://reviews.llvm.org/D68484

현실적으로 말해서, 크기를 고려할 때 이 패치가 병합될 예상 일정과 전체 가능성은 얼마입니까?

@MSxDOS LLVM 개발자에게 묻고 싶습니다. 일반적으로 패치의 크기가 패치가 병합되기를 원하는 소유자의 욕구보다 덜 중요할 것으로 예상하므로 LLVM이 패치를 보고 싶어하는 정도가 문제입니다.

내가 본 최신 상태는 다음과 같습니다. https://reviews.llvm.org/D69542#1836439

https://github.com/bytecodealliance/cranelift~~ https://github.com/bjorn3/rustc_codegen_cranelift가 작동 하면 어느 시점에서 관련성이 합니다.

@leeoniya , opt 빌드에 크레인 리프트를 사용할 단기 계획은 없습니다. 크레인 리프트에는 이를 가능하게 하는 데 필요한 최적화 작업이 많이 없습니다.

이 옵션 없이 앨리어싱이 있을 수 있다고 가정하는 것과 관련하여 컴파일러가 얼마나 보수적인지 알고 놀랐습니다. 예를 들어:

fn baz(s: &mut S) {
    if s.y < 10 {
        s.x = foo();
    }

    if s.y < 5 {
        s.x = foo();
    }
}

&mut 통해 구조체 멤버에 액세스하기 때문에 s.x 및 s.y 가 별칭을 지정할 수 있다고 가정하므로 s.y 대해 하나가 아닌 두 개의 메모리 액세스가 필요합니다. &mut 를 통한 회원 읽기/쓰기 횟수를 일반적인 프로그램에서 인터리브해야 하는 횟수를 고려할 때 정말 불행한 일입니다.

편집: 일부 테스트를 기반으로 하면 이러한 모든 읽기/쓰기에 영향을 미치지 않는 것 같습니다. 그래도 -Z mutable-noalias 를 사용하면 위의 예에서 이중 메모리 액세스가 수정되므로 일부 경우가 중단될 수 있습니다.

@PaulGrandperrin llvm@9fb46a452d4e5666828c95610ceac8dcd9e4ce16을 기반으로 하는 이 패치의 새 버전이 https://reviews.llvm.org/D69542에 있습니다. 다시 실행해 보시겠습니까?