Rust: LLVM 루프 최적화는 안전한 프로그램 충돌을 일으킬 수 있습니다.

최적화 된 코드의 LLVM IR은 다음과 같습니다.

; Function Attrs: noreturn nounwind readnone uwtable
define internal void @_ZN4main20h5ec738167109b800UaaE() unnamed_addr #0 {
entry-block:
  unreachable
}

이러한 종류의 최적화는 일반적으로 무인 유형에 적용되어야하는 주요 가정을 깨뜨립니다. 해당 유형의 값을 가질 수 없어야합니다.
rust-lang / rfcs # 1216은 이러한 유형을 Rust에서 명시 적으로 처리하도록 제안합니다. LLVM이이를 처리 할 필요가 없도록하고 필요할 때 발산을 보장하기 위해 적절한 코드를 삽입하는 데 효과적 일 수 있습니다 (IIUIC는 적절한 속성 또는 고유 호출로 달성 할 수 있음).
이 주제는 최근 LLVM 메일 링리스트에서도 논의되었습니다 : http://lists.llvm.org/pipermail/llvm-dev/2015-July/088095.html

분류 : 내가 지명

나쁘다! LLVM이 "예,이 루프는 정말 무한합니다"라고 말할 방법이 없다면 상류 토론이 해결 될 때까지 앉아서 기다려야 할 수도 있습니다.

무한 루프가 최적화되는 것을 방지하는 방법은 그 안에 unsafe {asm!("" :::: "volatile")} 를 추가하는 것입니다. 이것은 LLVM 메일 링리스트에 제안 된 llvm.noop.sideeffect 내장 함수와 유사하지만 일부 최적화를 방해 할 수 있습니다.
성능 손실을 방지하고 분기 함수 / 루프가 최적화되지 않도록 보장하기 위해, 무인 값이있는 경우 빈 최적화 할 수없는 루프 (예 : loop { unsafe { asm!("" :::: "volatile") } } )를 삽입하는 것으로 충분해야합니다. 범위.
LLVM이 더 이상 발산하지 않는 지점으로 발산해야하는 코드를 최적화하는 경우 이러한 루프는 제어 흐름을 계속 진행할 수 없도록 보장합니다.
LLVM이 발산 코드를 최적화 할 수없는 "운이 좋은"경우, 이러한 루프는 DCE에 의해 제거됩니다.

# 18785와 관련이 있습니까? UB가되는 것은 무한 재귀에 관한 것이지만 근본적인 원인은 비슷할 수 있습니다. LLVM은 중지하지 않는 것을 부작용으로 간주하지 않으므로 함수에 중지하지 않는 것 외에 다른 부작용이없는 경우 최적화하는 것이 좋습니다. 멀리.

헉

같은 문제입니다.

예, 같은 것 같습니다. 그 문제를 더 자세히 살펴보면 undef 를 얻는 방법을 보여 주며, (겉보기에 안전한) 프로그램 충돌을 만드는 것이 어렵지 않다고 가정합니다.

: +1 :

충돌, 또는 심장 출혈이 더 심할 수 있음 https://play.rust-lang.org/?gist=15a325a795244192bdce&version=stable

그래서 누군가가 이것을보고하기까지 얼마나 걸 렸는지 궁금합니다. :) 내 생각에 최선의 해결책은 LLVM에게 잠재적으로 무한 루프에 대해 너무 공격적이지 않도록 말할 수 있다면 당연히 최선의 해결책이 될 것입니다. 그렇지 않으면, 우리가 할 수있는 유일한 일은 Rust 자체에서 보수적 분석을 수행하여 다음을 결정하는 것입니다.

1. 루프가 종료됩니다 또는
2. 루프에는 부작용이 있습니다 (I / O 작업 등, 이것이 C에서 어떻게 정의되었는지 정확히 잊어 버림)

이 두 가지 모두 정의되지 않은 동작을 피하기에 충분해야합니다.

분류 : P- 중간

우리는 많은 노력을 기울이기 전에 LLVM이 무엇을할지 알고 싶습니다. 이것은 실제로 문제를 일으키지 않을 것 같습니다. 걱정할 하위 호환성 문제는 없습니다.

LLVM 메일 링리스트 토론에서 인용 :

 The implementation may assume that any thread will eventually do one of the following:
   - terminate
   - make a call to a library I/O function
   - access or modify a volatile object, or
   - perform a synchronization operation or an atomic operation

 [Note: This is intended to allow compiler transformations such as removal of empty loops, even
  when termination cannot be proven. — end note ]

@dotdash 인용하는 발췌 부분은 C ++ 사양에서 가져온 것입니다. 그것은 기본적으로 "[부작용이있는] 그것이 C로 정의되는 방법"에 대한 대답입니다 (또한 표준위원회에 의해 확인 됨 : http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1528) .htm).

LLVM IR의 예상되는 동작과 관련하여 약간의 혼란이 있습니다. https://llvm.org/bugs/show_bug.cgi?id=24078 은 LLVM IR에서 무한 루프의 의미론에 대한 정확하고 명시적인 사양이없는 것으로 보입니다. 그것은 역사적 이유와 편의를 위해 C ++의 의미와 일치합니다 (나는 분명히 시간을 나타내는 https://groups.google.com/forum/#!topic/llvm-dev/j2vlIECKkdE 만 추적했습니다. 무한 루프가 최적화되지 않았을 때 C / C ++ 사양이이를 허용하도록 업데이트되기 얼마 전).

스레드에서 가능한 한 효과적으로 C ++ 코드를 최적화하려는 욕구가 있음이 분명하지만 (즉, 무한 루프를 제거 할 기회도 고려) 동일한 스레드에서 여러 개발자 (LLVM에 적극적으로 기여하는 일부 포함)가 다른 언어에 필요하므로 무한 루프를 보존하는 기능에 관심을 보였습니다.

@ ranma42이 문제를 해결할 수있는 한 가지 가능성은 녹에서 이러한 루프를 감지하고 LLVM이이 최적화를 수행하지 못하도록 위 중 하나를 추가하는 것이기 때문입니다.

건전성 문제입니까? 그렇다면 태그를 지정해야합니다.

예, @ ranma42 의 예에 무효화 하는 방법을 보여줍니다. 놀이터 링크

블루스

정책은 건전성 문제이기도 한 잘못된 코드 문제 (즉, 대부분)에 I-wrong 태그를 지정해야한다는 것입니다.

따라서 이전 논의를 요약하기 위해 여기에서 볼 수있는 두 가지 선택 사항이 있습니다.

• LLVM이 솔루션을 제공 할 때까지 기다리십시오.
• 무한 루프 또는 무한 재귀가있을 수있는 곳에 no-op asm 문을 도입합니다 (# 18785).

후자는 최적화를 방해 할 수 있기 때문에 다소 나쁘기 때문에 우리는 기본적으로 종료를 스스로 증명할 수없는 곳에서 조금만 수행하고 싶을 것입니다. 또한 LLVM이 최적화하는 방법에 좀 더 묶어 이미징 할 수 있습니다. 즉, LLVM이 무한 루프 / 재귀로 간주 할 수있는 시나리오를 감지 할 수있는 경우에만 도입 할 수 있지만 (a) LLVM을 추적해야하고 (b ) 적어도 내가 가지고있는 것보다 더 깊은 지식이 필요합니다.

LLVM이 솔루션을 제공 할 때까지 기다리십시오.

이 문제를 추적하는 LLVM 버그는 무엇입니까?

참고 : while true {} 이 동작을 나타냅니다 . Lint를 기본적으로 오류로 업그레이드하고 현재 정의되지 않은 동작을 나타낼 수 있다는 메모를 받아야할까요?

또한 이것은 C에 대해 유효하지 않습니다.이 인수를 만드는 LLVM은 clang에 버그가 있음을 의미합니다.

void foo() { while (1) { } }

void create_null() {
        foo();

        int i = 0;
        while (i < 100) { i += 1; }
}

__attribute__((noreturn))
void use_null() {
        __builtin_unreachable();
}


int main() {
        create_null();
        use_null();
}

이것은 최적화와 충돌합니다. 이것은 C11 표준에서 잘못된 동작입니다 .

An iteration statement whose controlling expression is not a constant
expression, [note 156] that performs no  input/output  operations,
does  not  access  volatile  objects,  and  performs  no synchronization or
atomic operations in its body, controlling expression, or (in the case of
a for statement) its expression-3, may be   assumed   by   the
implementation to terminate. [note 157]

156: An omitted controlling expression is replaced by a nonzero constant,
     which is a constant expression.
157: This  is  intended  to  allow  compiler  transformations  such  as
     removal  of  empty  loops  even  when termination cannot be proven. 

"제어 표현식이 상수 표현식이 아닙니다"- while (1) { } , 1 는 상수 표현식이므로 제거 할 수 없습니다 .

루프 제거는 단순히 제거 할 수있는 최적화 단계입니까?

뿡뿡

LLVM의 bugzilla에서 버그 보고서를 찾았거나 채웠습니까? C ++ 무한 루프에서 _can_ 결코 종료되지 않는 동작은 정의되지 않은 동작이지만 C에서는 정의 된 동작입니다 (어떤 경우에는 안전하게 제거 할 수 있거나 다른 경우에는 할 수 없음).

@gnzlbg 지금 버그를 신고하고 있습니다.

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

# 42009에서 반복 :이 버그는 어떤 상황에서 기계 명령어가 전혀 포함되지 않은 외부 호출 가능 함수를 방출 할 수 있습니다. 이것은 결코 일어나지 않아야합니다. LLVM이 pub fn 를 올바른 코드로 호출 할 수 없다고 추론하는 경우 해당 함수의 본문으로 적어도 트랩 명령을 내 보냅니다.

이것은 오늘이 블로그 게시물에서 제기되었습니다 : https://blog.rom1v.com/2017/09/gnirehtet-rewritten-in-rust/

더 간단한 복제 : https://play.rust-lang.org/?gist=e622f8a672fbc57ecc63eb4450d2fc0a&version=stable

이에 대한 LLVM 버그는 https://bugs.llvm.org/show_bug.cgi?id=965(2006 년에 열림)입니다.

@zackw LLVM에는 TrapUnreachable 플래그가 있습니다. 나는 이것을 테스트하지 않았지만 LLVMRustCreateTargetMachine Options.TrapUnreachable = true; 을 추가하는 것으로 보입니다. 내가 측정을하지 않았지만 기본적으로 수행 할 수있을만큼 비용이 충분히 낮을 가능성이 있습니다.

@ oli-obk 불행히도 단순한 루프 삭제 패스가 아닙니다. 문제는 다음과 같은 광범위한 가정에서 발생합니다. 삭제되었습니다.

패치가있는 것 같습니다 : https://reviews.llvm.org/D38336

@sunfishcode , https://reviews.llvm.org/D38336 의 LLVM 패치가 10 월 3 일에 "수락"된 것 같습니다. LLVM의 릴리스 프로세스에 대한 업데이트를 제공 할 수 있습니까? 수용을 넘어선 다음 단계는 무엇이며,이 패치가 포함될 향후 LLVM 릴리스에 대해 알고 있습니까?

나는 llvmdev 스레드가 있다고 제안한 오프라인 사람들과 이야기했습니다. 스레드는 다음과 같습니다.

http://lists.llvm.org/pipermail/llvm-dev/2017-October/118558.html

이제 추가 변경이 필요하다는 결론을 내 렸습니다. 조금 더 시간이 걸리 겠지만 변화는 좋을 것 같습니다.

업데이트 해주셔서 감사하고 노력 해주셔서 감사합니다!

https://reviews.llvm.org/rL317729 가 LLVM에 포함되었습니다. 이 패치는 기본적으로 무한 루프가 정의 된 동작을 나타내도록하는 후속 패치를 포함 할 예정이므로 AFAICT는 대기만하면되고 결국에는 업스트림에서 해결 될 것입니다.

@zackw 이제 코드가없는 함수 문제를 해결하기 위해 # 45920을 만들었습니다.

@bstrie 예, 첫 번째 단계가 시작되었으며 LLVM이 기본적으로 정의 된 동작을 무한 루프로 제공하는 두 번째 단계를 진행 중입니다. 복잡한 변경 사항이며 완료하는 데 얼마나 걸릴지 아직 모르겠지만 여기에 업데이트를 게시하겠습니다.

지금은 이것을 재현 할 수 없습니다 : https://play.rust-lang.org/?gist=529bd5ab326f7b627e559f64d514312f&version=stable

@jsgf 여전히 재현. 릴리스 모드를 선택하셨습니까?

@kennytm 웁스, 신경 쓰지 마.

https://reviews.llvm.org/rL317729 가 LLVM에 포함되었습니다. 이 패치는 기본적으로 무한 루프가 정의 된 동작을 나타내도록하는 후속 패치를 포함 할 예정이므로 AFAICT는 대기만하면되고 결국에는 업스트림에서 해결 될 것입니다.

이 발언 이후 몇 달이 지났습니다. 후속 패치가 발생했는지 아니면 계속 발생할 것인지 아는 사람이 있습니까?

또는 llvm.sideeffect 내장 함수가 우리가 사용하는 LLVM 버전에 존재하는 것 같습니다.

https://github.com/rust-lang/rust/issues/38136 및 https://github.com/rust-lang/rust/issues/54214 와 같이 다가오는 panic_implementation 에서는 특히 나쁩니다. loop {} 이며 unsafe 코드없이 panic! UB가 모두 발생합니다. 그건 ... 일어날 수있는 상황이 더 나쁠 수도 있습니다.

이 문제를 다른 관점에서 보았습니다. 예를 들면 다음과 같습니다.

pub struct Container<'f> {
    string: &'f str,
    num: usize,
}

impl<'f> From<&'f str> for Container<'f> {
    #[inline(always)]
    fn from(string: &'f str) -> Container<'f> {
        Container::from(string)
    }
}

fn main() {
    let x = Container::from("hello");
    println!("{} {}", x.string, x.num);

    let y = Container::from("hi");
    println!("{} {}", y.string, y.num);

    let z = Container::from("hello");
    println!("{} {}", z.string, z.num);
}

이 예제는 stable, beta 및 nightly에서 안정적으로 segfault를 수행하며 모든 유형의 초기화되지 않은 값을 구성하는 것이 얼마나 쉬운 지 보여줍니다. 여기는 놀이터에 있습니다.

@SergioBenitez 그 프로그램은 segfault가 아니라 스택 오버플로로 종료됩니다 (디버그 모드에서 실행해야 함). 프로그램이 무한한 양의 스택 공간을 요구하여 무한히 반복되기 때문에 이것은 올바른 동작입니다. 이는 어느 시점에서 사용 가능한 스택 공간을 초과 할 것입니다. 최소한의 작업 예 .

릴리스 빌드에서 LLVM은 무한 재귀가 없다고 가정하고이를 최적화합니다 ( mwe ). 이것은 루프 AFAICT와 관련이 없지만 https://stackoverflow.com/a/5905171/1422197 과 관련이

@gnzlbg 죄송합니다. 정확하지 않습니다.

프로그램 segfault는 릴리스 모드에서 실행됩니다. 그게 전체 요점입니다. 최적화는 LLVM과 Rust의 의미가 여기서 일치하지 않는다는 것입니다. 즉, 내가 초기화되지 않은 메모리를 사용하고, 임의의 메모리를 검사하고, 유형간에 임의로 캐스트 할 수 있도록하는 rustc로 안전한 Rust 프로그램을 작성하고 컴파일 할 수 있습니다. 언어의 의미. 이 스레드에서 설명하는 것과 동일한 점이 있습니다. 원래 프로그램은 디버그 모드에서도 segfault를 수행하지 않습니다.

당신은 또한 여기서 일어나는 _ 다른 _, 비-루프 최적화가 있다고 제안하는 것 같습니다. 그럴 가능성은 크지 않지만, 그럴 경우 별도의 문제가있을 수 있습니다. 내 생각에는 LLVM이 꼬리 재귀를 인식하고 무한 루프로 처리하고 다시 최적화 하여이 문제가 정확히 무엇인지 확인합니다.

@gnzlbg 글쎄, 무한 재귀에서 최적화의 mwe를 약간 변경하면 ( 여기 ), NonZeroUsize 의 초기화되지 않은 값이 생성됩니다 (이는 ... 0이므로 잘못된 값).

그리고 그것은 @SergioBenitez 가 포인터를 사용하여 segfault를 생성하는 것을 제외하고는 그들의 예제에서도 한 일입니다.

@SergioBenitez 프로그램에 디버그 및 릴리스 모두에서 스택 오버플로가 있다는

그렇다면 @SergioBenitez 예제에서 loop 찾을 수 없으므로이 문제가 어떻게 적용 될지 모르겠습니다 (이 문제는 결국 무한한 loop s입니다). 내가 틀렸다면 귀하의 예에서 loop 를 알려주십시오.

언급했듯이 LLVM은 무한 재귀가 발생할 수 없다고 가정하지만 (모든 스레드가 결국 종료된다고 가정), 이는이 문제와는 다른 문제입니다.

나는 LLVM이 수행하는 최적화 또는 프로그램 중 하나에 대해 생성 된 코드를 검사하지 않았지만 segfault가 모든 일이 발생하면 segfault가 건전하지 않다는 점에 유의하십시오. 특히 (스택 탐색 + 스택 종료 후 매핑되지 않은 가드 페이지에 의해) 포착되고 메모리 안전 문제를 일으키지 않는 스택 오버플로도 segfault로 표시됩니다. 물론 세그 폴트는 메모리 손상이나 거친 쓰기 / 읽기 또는 기타 건전성 문제를 나타낼 수도 있습니다.

@rkruppe 임의의 메모리 위치에 대한 참조를 생성 할 수 있도록 허용하고 이후에 참조를 읽었 기 때문에 내 프로그램이 segfault됩니다. 프로그램은 임의의 메모리 위치를 대신 쓰기 위해 사소하게 수정 될 수 있으며 너무 어렵지 않게 _particular_ 메모리 위치를 읽거나 쓸 수 있습니다.

@gnzlbg 프로그램은 릴리스 모드에서 스택 오버플로를 _하지 않습니다 _. 릴리스 모드에서 프로그램은 함수 호출을 0으로 만듭니다. 스택은 순전히 로컬을 할당하기 위해 한정된 횟수로 푸시됩니다.

이 프로그램은 릴리스 모드에서 스택 오버플로가 발생하지 않습니다.

그래서? 중요한 것은 기본적으로 fn foo() { foo() } 인 예제 프로그램이 LLVM에서 허용하지 않는 무한 재귀를 가지고 있다는 것입니다.

중요한 것은 기본적으로 fn foo () {foo ()} 인 예제 프로그램이 LLVM에서 허용하지 않는 무한 재귀를 가지고 있다는 것입니다.

나는 당신이 왜 이것을 해결한다고 말하는지 모르겠습니다. 무한 재귀 및 루프 UB를 고려하고 그에 따라 최적화하는 LLVM은 Rust에서 안전하지만이 전체 문제의 요점입니다!

https://reviews.llvm.org/rL317729의 작성자는 아직 후속 패치를 구현하지 않았 음을 확인합니다.

루프가 최적화되지 않도록 오늘 @llvm.sideeffect 호출을 삽입 할 수 있습니다. 이는 일부 최적화를 비활성화 할 수 있지만 이론적으로는 주요 최적화를 이해하는 방법을 배웠으므로 너무 많지는 않습니다. @llvm.sideeffect 호출을 모든 루프 또는 루프로 바뀔 수있는 것들 (재귀, 풀기, 인라인 asm , 기타?)에 넣으면 이론적으로 문제를 해결하기에 충분합니다.

분명히 두 번째 패치를 적용하는 것이 더 좋을 것이므로이를 수행 할 필요가 없습니다. 언제 다시 구현할지 모르겠습니다.

약간의 차이가 있지만 소재인지 아닌지는 잘 모르겠습니다.

재귀

#[allow(unconditional_recursion)]
#[inline(never)]
pub fn via_recursion<T>() -> T {
    via_recursion()
}

fn main() {
    let a: String = via_recursion();
}

define internal void @_ZN10playground4main17h1daf53946e45b822E() unnamed_addr #2 personality i32 (i32, i32, i64, %"unwind::libunwind::_Unwind_Exception"*, %"unwind::libunwind::_Unwind_Context"*)* <strong i="9">@rust_eh_personality</strong> {
_ZN4core3ptr13drop_in_place17h95538e539a6968d0E.exit:
  ret void
}

고리

#[inline(never)]
pub fn via_loop<T>() -> T {
    loop {}
}

fn main() {
    let b: String = via_loop();
}

define internal void @_ZN10playground4main17h1daf53946e45b822E() unnamed_addr #2 {
start:
  unreachable
}

메타

Rust 1.29.1, 릴리스 모드에서 컴파일, LLVM IR보기.

일반적으로 재귀 (특성 객체, C FFI 등)를 감지 할 수 없다고 생각하므로 호출이 증명되지 않는 한 거의 모든 호출 사이트에서 llvm.sideeffect 를 사용해야합니다. 사이트는 재귀하지 않습니다. fn main() { main() } 와 같은 가장 사소한 프로그램을 제외하고는 입증 될 수있는 경우에 대한 재귀가 없음을 증명하려면 절차 간 분석이 필요합니다. 이 수정 사항을 구현하면 어떤 영향을 미치고이 문제에 대한 대체 솔루션이 있는지 확인하는 것이 좋습니다.

@gnzlbg 맞습니다 . 호출 사이트가 아닌 함수 항목에 @ llvm.sideeffects를 넣을 수 있습니다.

이상하게도 @SergioBenitez '테스트 케이스의 SEGFAULT를 로컬에서 재현 할 수 없습니다.

또한 스택 오버플로의 경우 다른 오류 메시지가 있어야하지 않습니까? "스택 오버플로"정도를 인쇄 할 코드가 있다고 생각 했습니까?

@RalfJung 디버그 모드에서 시도 했습니까? (내 컴퓨터와 플레이 그라운드의 디버그 모드에서 스택 오버플로를 안정적으로 재현 할 수 있으므로, 그렇지 않은 경우 버그를 채워야 할 수도 있습니다). --release 에서는 모든 코드가 잘못 최적화 되었기 때문에 스택 오버플로가 발생하지 않습니다.

안녕하세요.

호출 사이트가 아닌 함수 항목에 @ llvm.sideeffects를 넣을 수는 있지만 사실입니다.

llvm.sideeffects 방지하는 최적화를 정확히 알지 못하면 최선의 방법이 무엇인지 알기 어렵습니다. @llvm.sideeffects 를 최대한 적게 생성하는 것이 가치가 있습니까? 그렇지 않은 경우 모든 함수 호출에 삽입하는 것이 가장 간단 할 수 있습니다. 그렇지 않으면 IIUC, @llvm.sideeffect 가 필요한지 여부는 호출 사이트가 수행하는 작업에 따라 다릅니다.

trait Foo {
    fn foo(&self) { self.bar() }
    fn bar(&self);
}

struct A;
impl Foo for A {
    fn bar(&self) {} // not recursive
}
struct B;
impl Foo for B {
    fn bar(&self) { self.foo() } // recursive
}

fn main() {
    let a = A;
    a.bar(); // Ok - no @llvm.sideeffect needed anywhere
    let b = B;
    b.bar(); // We need @llvm.sideeffect on this call site
    let c: &[&dyn Foo] = &[&a, &b];
    for i in c {
        i.bar(); // We need @lvm.sideeffect here too
    }
}

AFAICT, 우리는 그것들이 제거되는 것을 막기 위해 함수 안에 @llvm.sideeffect 를 넣어야합니다. 그래서 이러한 "최적화"가 그만한 가치가 있다고하더라도 현재 모델과 관련이 있다고 생각하지 않습니다. 그렇더라도 이러한 최적화는 재귀가 없음을 증명할 수있는 능력에 의존합니다.

디버그 모드에서 시도 했습니까? (내 컴퓨터와 플레이 그라운드의 디버그 모드에서 스택 오버플로를 안정적으로 재현 할 수 있으므로, 그렇지 않은 경우 버그를 채워야 할 수도 있습니다)

물론입니다.하지만 디버그 모드에서는 LLVM이 루프 최적화를 수행하지 않으므로 문제가 없습니다.

프로그램이 디버그 모드에서 스택 오버플로되면 UB를 만들 수있는 LLVM 라이센스를 제공해서는 안됩니다. 문제는 최종 프로그램에 UB가 있는지 알아 내고 IR을 쳐다 보면 알 수 없습니다. 그것은 segfaults, 그러나 나는 이유를 모른다. 그러나 스택 오버플로 프로그램을 세그 폴트 프로그램으로 "최적화"하는 것은 나에게 버그처럼 보입니다.

프로그램이 디버그 모드에서 스택 오버플로되면 UB를 만들 수있는 LLVM 라이센스를 제공해서는 안됩니다.

그러나 스택 오버플로 프로그램을 세그 폴트 프로그램으로 "최적화"하는 것은 나에게 버그처럼 보입니다.

C에서 실행 스레드는 종료, 휘발성 메모리 액세스, I / O 또는 동기화 원자 작업을 수행하는 것으로 간주됩니다. LLVM-IR이 우연히 또는 의도적으로 동일한 의미를 갖도록 진화하지 않았다면 놀랍습니다.

Rust 코드에는 절대 종료되지 않는 실행 스레드가 포함되어 있으며 C에서 UB가 아닌 데 필요한 작업을 수행하지 않습니다. 정의되지 않은 동작을 가진 C 프로그램과 동일한 LLVM-IR을 생성한다고 생각합니다. , 그래서 LLVM이이 Rust 프로그램을 잘못 최적화하는 것이 놀랍지 않다고 생각합니다.

그것은 segfaults, 그러나 나는 이유를 모른다.

LLVM은 무한 재귀를 제거하므로 @SergioBenitez가 위에서 언급했듯이 프로그램은 다음을 진행합니다.

임의의 메모리 위치에 대한 참조가 생성되도록 허용되었으며 이후에 참조를 읽었습니다.

이를 수행하는 프로그램의 일부는 다음과 같습니다.

let x = Container::from("hello");  // invalid reference created here
println!("{} {}", x.string, x.num);  // invalid reference dereferenced here

여기서 Container::from 는 무한 재귀를 시작하고 LLVM은 결코 일어날 수 없다는 결론을 내리고 임의의 값으로 대체 한 다음 역 참조됩니다. 이것이 잘못 최적화되는 여러 방법 중 하나를 여기에서 볼 수 있습니다 : https://rust.godbolt.org/z/P7Snex 놀이터에서 (https://play.rust-lang.org/?gist=f00d41cc189f9f6897d429350f3781ec&version=stable&mode = release & edition = 2015)이 최적화로 인해 디버그 빌드와 릴리스에서 다른 패닉이 발생하지만 UB는 UB가 UB입니다.

Rust 코드에는 절대 종료되지 않는 실행 스레드가 포함되어 있으며 C에서 UB가 아닌 데 필요한 작업을 수행하지 않습니다. 정의되지 않은 동작을 가진 C 프로그램과 동일한 LLVM-IR을 생성한다고 생각합니다. , 그래서 LLVM이이 Rust 프로그램을 잘못 최적화하는 것이 놀랍지 않다고 생각합니다.

나는 이것이 무한 루프 문제와 같은 버그가 아니라고 위에서 주장했다는 인상을 받았습니다. 그때 당신의 메시지를 잘못 읽은 것 같습니다. 혼란을 드려 죄송합니다.

그렇다면 좋은 다음 단계는 우리가 생성하는 IR에 llvm.sideffect 를 뿌려서 벤치 마크를하는 것 같습니다.

C에서 실행 스레드는 종료, 휘발성 메모리 액세스, I / O 또는 동기화 원자 작업을 수행하는 것으로 간주됩니다.

Btw, 이것은 완전히 정확하지 않습니다. 부작용을 포함하지 않더라도 상수 조건 (예 : while (true) { /* ... */ } ) 이 있는 루프는 표준에서 명시 적으로 허용됩니다. 이것은 C ++에서 다릅니다. LLVM은 여기서 C 표준을 올바르게 구현하지 않습니다.

나는 이것이 무한 루프 문제와 같은 버그가 아니라고 위에서 주장했다는 인상을 받았습니다.

비 종료 Rust 프로그램의 동작은 항상 정의되는 반면 비 종료 LLVM-IR 프로그램의 동작은 특정 조건이 충족되는 경우에만 정의됩니다.

이 문제는 생성 된 LLVM-IR의 동작이 정의되도록 무한 루프에 대한 Rust의 구현을 수정하는 것에 관한 것이라고 생각했으며, 이에 대해 @llvm.sideeffect 는 꽤 좋은 솔루션처럼 들렸습니다.

@SergioBenitez 는 재귀를 사용하여 비 종결 Rust 프로그램을 만들 수도 @rkruppe 는 무한 재귀와 무한 루프가 동등하므로 둘 다 동일한 버그

나는이 두 가지 문제가 관련되어 있거나 심지어 같은 버그라는 데 동의하지 않지만, 나에게는이 두 가지 문제가 약간 다르게 보입니다.

• 솔루션 측면에서는 최적화 장벽 ( @llvm.sideeffect )을 비 종료 루프에만 적용하여 모든 단일 Rust 함수에 적용합니다.

• 가치 측면에서 무한 loop 는 프로그램이 절대 종료되지 않기 때문에 유용합니다. 무한 재귀의 경우 프로그램 종료 여부는 최적화 수준 (예 : LLVM이 재귀를 루프로 변환하는지 여부)에 따라 달라지며 프로그램 종료시기와 방법은 플랫폼 (스택 크기, 보호 된 보호 페이지 등)에 따라 다릅니다. Rust 구현을 사운드로 만들기 위해서는 둘 다 수정해야하지만, 무한 재귀의 경우 사용자가 프로그램을 영원히 재귀하도록 의도했다면 사운드 구현은 항상 영원히 재귀하지는 않는다는 의미에서 여전히 "잘못된"것입니다.

솔루션 측면에서 우리는 최적화 장벽 (@ llvm.sideeffect)을 비 종료 루프에만 적용하는 것에서 모든 단일 Rust 함수에 적용합니다.

루프 본문에 실제로 부작용 (외부 함수 호출과 같이 잠재적 으로)이 있고 따라서 llvm.sideeffect 삽입이 필요하지 않음을 보여주는 데 필요한 분석은 매우 까다 롭습니다. 무한 재귀의 일부일 수있는 함수에 대해 동일하게 표시되는 크기입니다. 대부분의 Rust 루프는 반복자를 포함하기 때문에 많은 최적화를 먼저 수행하지 않고 루프가 종료되고 있음을 증명하는 것도 어렵습니다. 그래서 저는 우리가 llvm.sideeffect 를 대부분의 루프에 넣는다 고 생각합니다. 물론 루프를 포함하지 않는 함수가 꽤 많이 있지만 여전히 나에게 질적 인 차이가 아닌 것 같습니다.

나는 무한 루프 사건을 해결하기 위해, 문제를 정확하게 이해한다면, 삽입하기에 충분해야한다 llvm.sideeffect 에 loop { ... } 및 while <compile-time constant true> { ... } 곳에는 루프의 몸이 더 포함되어 있지 않습니다 break 표현식. 이것은 무한 루프에 대한 C ++ 시맨틱과 Rust 시맨틱의 차이를 포착합니다. Rust에서는 C ++와 달리 컴파일러가 루프가 컴파일 타임에 _doesn't_ 알 수있을 때 종료된다고 가정 할 수 없습니다. (신체가 당황 할 수있는 루프의 정면에서 정확성에 대해 얼마나 걱정해야하는지 잘 모르겠지만 나중에 언제든지 개선 할 수 있습니다.)

무한 재귀에 대해 무엇을해야할지 모르겠지만, 무관 한 세그 폴트로 무한 재귀를 최적화하는 것은 바람직한 행동이 아니라는 RalfJung에 동의합니다.

헉

문제를 올바르게 이해하고 무한 루프 케이스를 수정하려면 llvm.sideeffect를 루프 {...}에 삽입하는 것으로 충분해야합니다.{...} 루프의 본문에 break 표현식이 없습니다.

예를 들어 loop { if false { break; } } 는 break 표현식이 포함 된 무한 루프이지만 llvm이 제거하지 못하도록 @llvm.sideeffect 를 삽입해야합니다. AFAICT 우리는 루프가 항상 종료된다는 것을 증명할 수 없다면 @llvm.sideeffect 를 삽입해야합니다.

뿡뿡

loop { if false { break; } } 는 break 표현식을 포함하는 무한 루프이지만 llvm이이를 제거하지 못하도록 @llvm.sideeffect 를 삽입해야합니다.

흠, 예, 그거 귀찮습니다. 그러나 우리는 _ 완벽 할 필요는 없습니다. 보수적으로 옳습니다. 같은 루프

while spinlock.load(Ordering::SeqCst) != 0 {}

( std::sync::atomic 문서에서) 제어 조건이 일정하지 않기 때문에 @llvm.sideeffect 가 필요하지 않다는 것을 쉽게 알 수 있습니다 (원자로드 작업이 LLVM 목적의 부작용으로 더 잘 계산 됨). , 또는 우리는 더 큰 문제가 있습니다). 프로그램 생성기에 의해 방출 될 수있는 유한 루프의 종류,

loop {
    if /* runtime-variable condition */ { break }
    /* more stuff */
}

또한 귀찮아서는 안됩니다. 사실, "루프 본문에 중단 식 없음"규칙이 잘못되는 경우가 있습니까? _besides_

loop {
    if /* provably false at compile time */ { break }
}

?

이 문제는 생성 된 LLVM-IR의 동작이 정의되도록 무한 루프에 대한 Rust의 구현을 수정하는 것이라고 생각했으며, 이에 대해 @ llvm.sideeffect는 꽤 좋은 솔루션처럼 들렸습니다.

그럴 수 있지. 그러나 말했듯이 문제 (Rust 의미론과 LLVM 의미론 간의 불일치)는 실제로 루프가 아니라 비 종료에 관한 것입니다. 그래서 저는 그것이 우리가 여기서 추적해야 할 것이라고 생각합니다.

헉

문제를 올바르게 이해하고 무한 루프 케이스를 수정하려면 llvm.sideeffect를 루프 {...}에 삽입하는 것으로 충분해야합니다.{...} 루프의 본문에 break 표현식이 없습니다. 이것은 무한 루프에 대한 C ++ 시맨틱과 Rust 시맨틱의 차이를 포착합니다. Rust에서는 C ++와 달리 컴파일러가 루프가 컴파일 타임에 알 수있을 때 종료한다고 가정 할 수 없습니다. (신체가 당황 할 수있는 루프의 정면에서 정확성에 대해 얼마나 걱정해야하는지 잘 모르겠지만 나중에 언제든지 개선 할 수 있습니다.)

설명하는 것은 C를 유지합니다. Rust에서는 모든 루프가 분기 될 수 있습니다. 다른 모든 것은 타당하지 않을 것입니다.

예를 들어

while test_fermats_last_theorem_on_some_random_number() { }

Rust에서는 괜찮은 프로그램이고 (C도 C ++도 아닙니다), 부작용없이 영원히 반복됩니다. 따라서 우리가 종료 할 것이라는 것을 증명할 수있는 것을 제외하고는 모든 루프 여야

헉

"루프 본문에 중단 식 없음"규칙이 잘못되는 경우가 있습니까?

if /*compile-time condition */ 뿐만이 아닙니다. 모든 제어 흐름이 영향을 받고 ( while , match , for , ...) 런타임 조건도 영향을받습니다.

그러나 우리는 완벽 할 필요는 없습니다. 단지 보수적으로 옳습니다.

중히 여기다:

fn foo(x: bool) { loop { if x { break; } } }

여기서 x 는 런타임 조건입니다. 여기서 @llvm.sideeffect 보내지 않으면 사용자가 foo(false) 어딘가에 작성하면 foo 가 인라인 될 수 있으며 지속적인 전파 및 데드 코드 제거로 루프가 부작용이없는 무한 루프로 인해 최적화 오류가 발생합니다.

그것이 의미가 있다면, LLVM이 할 수있는 한 가지 변환은 foo 를 foo_opt 로 바꾸는 것입니다.

fn foo_opt(x: bool) { if x { foo(true) } else { foo(false) } }

두 분기가 독립적으로 최적화되고 @llvm.sideeffect 사용하지 않으면 두 번째 분기가 잘못 최적화됩니다.

즉, @llvm.sideeffect 를 생략 할 수 있으려면 LLVM이 어떤 상황에서도 해당 루프를 잘못 최적화 할 수 없음을 증명해야합니다. 이것을 증명하는 유일한 방법은 루프가 항상 종료된다는 것을 증명하거나, 종료되지 않는 경우 무조건적으로 잘못된 최적화를 방지하는 작업 중 하나를 수행한다는 것을 증명하는 것입니다. 그럼에도 불구하고 루프 분할 / 필링과 같은 최적화는 하나의 루프를 일련의 루프로 변환 할 수 있으며 그중 하나가 @llvm.sideeffect 를 갖지 않는 것으로도 충분합니다.

이 버그에 대한 모든 것은 rustc 에서보다 LLVM에서 해결하는 것이 훨씬 쉬울 것 같습니다. (면책 조항 :이 두 프로젝트의 코드베이스를 잘 모릅니다)

내가 이해하는 바와 같이, LLVM의 수정은 최적화를 실행 (비 종료 입증 || 둘 중 하나를 증명할 수 없음)에서 비 종료가 입증 될 수있을 때만 (또는 그 반대) 실행으로 변경하는 것입니다. 나는 이것이 (어떤 식 으로든) 쉽다고 말하는 것이 아니지만 LLVM은 이미 (내 생각에) 루프의 (비) 종료를 증명하는 코드를 포함하고 있습니다.

반면에 rustc 는 @llvm.sideeffect 만 추가 할 수 있으며, 이는 비 종료를 부적절하게 사용하는 최적화를 "단지"비활성화하는 것보다 최적화에 더 많은 영향을 미칠 수 있습니다. 그리고 rustc 는 루프의 (비) 종료를 감지하기 위해 새로운 코드를 삽입해야합니다.

따라서 앞으로의 길은 다음과 같을 것이라고 생각합니다.

1. 문제를 해결하기 위해 모든 루프 및 함수 호출에 @llvm.sideeffect 추가
2. 비 종료 루프에서 잘못된 최적화를 수행하지 않도록 LLVM을 수정하고 @llvm.sideeffects

이것에 대해 어떻게 생각하십니까? 1 단계의 성능 영향이 너무 끔찍하지 않기를 바랍니다. 2가 구현되면 사라지는 것이라 할지라도…

@sunfishcode 두 번째 패치가 될 수있는 @Ekleog : https://lists.llvm.org/pipermail/llvm-dev/2017-October/118595.html

기능 속성 제안의 일부는
동작을 정의하도록 LLVM IR의 기본 의미를 변경합니다.
무한 루프를 사용한 다음 potential-UB에 옵트 팅하는 속성을 추가합니다. 그래서
그렇게하면 @ llvm.sideeffect의 역할이 조금
미묘한-C와 같은 언어의 프론트 엔드가 선택하는 방법이 될 것입니다.
기능에 대한 잠재적 인 UB로 전환 한 다음 개별
그 함수의 루프.

LLVM을 공평하게하기 위해 컴파일러 작성자는 "루프가 종료되지 않음을 증명하는 최적화를 작성하여 반복적으로 최적화 할 수 있습니다!"라는 관점에서이 주제에 접근하지 않습니다. 대신 루프가 종료되거나 부작용이 있다는 가정은 일반적인 컴파일러 알고리즘에서 자연스럽게 발생합니다. 이 문제를 해결하는 것은 단순히 기존 코드를 수정하는 것이 아닙니다. 상당한 양의 새로운 복잡성이 필요합니다.

함수 본문에 "부작용이 없는지"여부를 테스트하기 위해 다음 알고리즘을 고려하십시오. 본문의 명령에 잠재적 인 부작용이있는 경우 함수 본문에 부작용이있을 수 있습니다. 멋지고 간단합니다. 그런 다음 나중에 "부작용없이"함수 호출이 삭제됩니다. 멋있는. 단, 분기 명령어는 부작용이없는 것으로 간주되므로 분기 만 포함하는 함수는 무한 루프가 포함되어 있어도 부작용이없는 것처럼 보입니다. 죄송합니다.

고정 가능합니다. 다른 사람이 이것에 관심이 있다면, 저의 기본 아이디어는 "부작용 있음"이라는 개념을 "실제 부작용 있음"과 "종료되지 않을 수 있음"이라는 독립적 인 개념으로 분리하는 것입니다. 그런 다음 전체 옵티 마이저를 살펴보고 "부작용이 있음"에 관심이있는 모든 위치를 찾고 실제로 필요한 개념을 파악합니다. 그런 다음 루프의 일부가 아닌 분기에 메타 데이터를 추가하도록 루프 패스를 가르치거나, 비관적 인 상황을 피하기 위해 루프가 유한 한 것으로 입증됩니다.

가능한 타협은 사용자가 문자 그대로 빈 loop { } (또는 이와 유사한) 또는 무조건 재귀 (이미 lint가 있음)를 쓸 때 rustc insert @ llvm.sideeffect를 갖는 것일 수 있습니다. 이 절충안은 실제로 무한한 효과없는 회전 루프를 의도하는 사람들이 그것을 얻을 수있게하면서 다른 모든 사람들의 오버 헤드를 피할 수있게합니다. 물론,이 타협이 안전한 코드를 크래시하는 것을 불가능하게 만들지는 않지만 실수로 발생할 가능성을 줄일 수 있으며 구현하기가 쉬워야합니다.

대신 루프가 종료되거나 부작용이 있다는 가정은 일반적인 컴파일러 알고리즘에서 자연스럽게 발생합니다.

이러한 변형의 정확성에 대해 생각하기 시작하면 완전히 부자연 스럽습니다. 솔직히 말해서 나는 여전히이 가정을 허용하는 것이 C의 큰 실수라고 생각합니다.

신체의 어떤 지시에 잠재적 인 부작용이있는 경우 기능 본체에 부작용이있을 수 있습니다.

공식적으로 사물을보기 시작할 때 "비 종결"이 일반적으로 효과로 간주되는 타당한 이유가 있습니다. (Haskell은 순수하지 않으며 두 가지 효과가 있습니다 : 비 종료 및 예외.)

가능한 타협은 사용자가 문자 그대로 빈 루프 {} (또는 유사) 또는 무조건 재귀 (이미 lint가 있음)를 작성할 때 rustc insert @ llvm.sideeffect를 갖는 것일 수 있습니다. 이 절충안은 실제로 무한한 효과없는 회전 루프를 의도하는 사람들이 그것을 얻을 수있게하면서 다른 모든 사람들의 오버 헤드를 피할 수있게합니다. 물론,이 타협이 안전한 코드를 크래시하는 것을 불가능하게 만들지는 않지만 실수로 발생할 가능성을 줄일 수 있으며 구현하기가 쉬워야합니다.

직접 언급했듯이 이것은 여전히 ​​잘못되었습니다. 나는 우리가 틀렸다고 알고 있는 "해결책"을 받아 들여야한다고 생각하지 않습니다. 컴파일러는 우리 인프라의 필수적인 부분이므로 아무 일도 일어나지 않기를 바라면 안됩니다. 이것은 견고한 기초를 구축하는 방법이 아닙니다.

여기서 일어난 일은 "컴파일러에서 우리가 원하는 것 "으로 시작하여 사양을 만드는 대신 컴파일러가 수행 한 작업을 중심으로 정확성 개념이 구축되었다는 것입니다. 올바른 컴파일러는 항상 종료되는 프로그램으로 분기되는 프로그램을 기간으로 바꾸지 않습니다. 나는 이것이 다소 자명하다고 생각하지만 Rust가 합리적인 유형 시스템을 가지고 있기 때문에 이것은 유형에서 분명히 목격되기 때문에 문제가 정기적으로 발생하는 이유입니다.

우리가 작업하고있는 제약 조건 (즉, LLVM)을 감안할 때, 우리가해야 할 일은 모든 분기 실행이 무한히 많은 것을 "실행"할 수 있도록 충분한 위치에 llvm.sideeffect 를 추가하는 것입니다. 그런 다음 합리적인 기준에 도달했으며 필요하지 않음을 보장 할 수있을 때 이러한 주석을 제거하는 방식으로 개선 사항에 대해 이야기 할 수 있습니다.

내 요점을 더 정확하게 설명하기 위해 다음은 pick_a_number_greater_2 어떤 종류의 큰 정수를 (비 결정적으로) 반환하는 건전한 Rust 상자라고 생각합니다.

fn test_fermats_last_theorem() -> bool {
  let x = pick_a_number_greater_2();
  let y = pick_a_number_greater_2();
  let z = pick_a_number_greater_2();
  let n = pick_a_number_greater_2();
  // x^n + y^n = z^n is impossible for n > 2
  pow(x, n) + pow(y, n) != pow(z, n)
}

pub fn diverge() -> ! {
  while test_fermats_last_theorem() { }
  // This code is unreachable, as proven by Andrew Wiles
  unsafe { mem::transmute(()) }
}

분기하는 루프를 컴파일하면 버그이며 수정해야합니다.

이 문제를 순진하게 수정하는 데 얼마나 많은 성능이 필요한지에 대한 수치도 아직 없습니다. 그렇게하기 전까지는 위와 같은 프로그램을 고의로 중단 할 이유가 없습니다.

실제로 fn foo() { foo() } 는 리소스 고갈로 인해 항상 종료되지만 Rust 추상 머신에는 무한히 큰 스택 프레임 (AFAIK)이 있으므로 해당 코드를 fn foo() { loop {} } 로 변환하는 것이 유효합니다. 종료됩니다 (또는 훨씬 나중에 우주가 얼어 붙을 때). 이 변환이 유효해야합니까? 그렇지 않으면 종료를 증명할 수없는 경우 테일 호출 최적화를 수행 할 수 없기 때문에 그렇습니다. 이는 불행한 일입니다.

주어진 루프, 재귀, ...가 항상 종료된다는 것을 나타내는 unsafe 내장 함수를 갖는 것이 합리적일까요? N1528 은 루프가 종료되는 것으로 가정 할 수없는 경우, 링크드리스트를 순회하는 포인터 코드에 루프 퓨전을 적용 할 수 없다는 예를 제공합니다. 링크드리스트가 순환 될 수 있고 링크드리스트가 순환이 아님을 증명하는 것은 현대 컴파일러가 할 수있는 것이 아닙니다. 하다.

이 건전성 문제를 영원히 해결해야한다는 데 절대적으로 동의합니다. 그러나 우리가 진행하는 방식은 "불필요하다는 것을 증명할 수없는 모든 곳에 llvm.sideeffect 추가"하면 오늘날 올바르게 컴파일 된 프로그램의 코드 품질이 저하 될 수 있다는 가능성을 염두에 두어야합니다. 이러한 우려는 궁극적으로 사운드 컴파일러의 필요성에 의해 무시되지만, 성능 저하를 피하고 평균적으로 평균 Rust 프로그래머의 삶의 질을 향상시키는 대가로 적절한 수정을 약간 지연시키는 방식으로 진행하는 것이 현명 할 수 있습니다. 시각. 내가 제안:

• 장기적인 건전성 버그 (# 10184)에 대한 잠재적으로 성능이 저하되는 다른 수정과 마찬가지로, 야생에서 코드베이스에 대한 성능 영향을 평가할 수 있도록 -Z 플래그 뒤에 수정을 구현해야합니다.
• 영향이 무시할 수있는 수준 인 것으로 판명되면 기본적으로 수정을 켤 수 있습니다.
• 그러나 실제 회귀가있는 경우 해당 데이터를 LLVM 사용자에게 가져와 LLVM을 먼저 개선 할 수 있습니다 (또는 회귀를 먹고 나중에 수정하도록 선택할 수 있지만 어쨌든 정보에 입각 한 결정을 내릴 수 있습니다)
• 회귀로 인해 기본적으로 수정을 사용하지 않기로 결정한 경우 적어도 구문 적으로 비어있는 루프에 llvm.sideeffect 을 추가하여 진행할 수 있습니다. 이는 다소 일반적이며 잘못 컴파일되어 여러 사람이 비참하게 지출하게됩니다. 이상한 문제 (# 38136, # 47537, # 54214 등)를 디버깅하는 데 몇 시간이 걸리므로이 완화 방법 이 건전성 버그와 관련이 없더라도 적절한 문제를 해결하는 동안 개발자에게 실질적인 이점이 있습니다. 버그 수정.

물론, 이러한 관점은이 문제가 수년 동안 지속되어 왔다는 사실에서 알 수 있습니다. 새로운 회귀라면 더 빨리 수정하거나 도입 한 PR을 되돌릴 수 있습니다.

한편,이 문제가 열려있는 한 https://doc.rust-lang.org/beta/reference/behavior-considered-undefined.html 에서 언급해야합니까?

주어진 루프, 재귀, ...가 항상 종료된다는 것을 나타내는 unsafe 내장 함수를 갖는 것이 합리적일까요?

std::hint::reachable_unchecked ?

덧붙여서 나는 TCP 메시지 시스템에 대한 실제 코드를 작성하는 것을 만났습니다. 정지를위한 실제 메커니즘을 넣을 때까지 무한 루프를 임시로 사용했지만 스레드가 즉시 종료되었습니다.

누군가 테스트 케이스 코드 골프를하고 싶은 경우 :

fn main() {
    (|| loop {})()
}

```
$ 카고 런-릴리즈
잘못된 명령어 (코어 덤프 됨)

누군가 테스트 케이스 코드 골프를하고 싶은 경우 :

pub fn main() {
   (|| loop {})()
}

https://github.com/rust-lang/rust/pull/59546에 @sfanxiang 에 의해 추가 된 -Z insert-sideeffect rustc 플래그를 사용하면 계속 반복됩니다. :)

전에:

main:
  ud2

후:

main:
.LBB0_1:
  jmp .LBB0_1

그건 그렇고, 이것을 추적하는 LLVM 버그는 https://bugs.llvm.org/show_bug.cgi?id=965 이며 아직이 스레드에 게시 된 적이 없습니다.

이 스레드에 아직 게시 한 적이 없습니다.

https://github.com/rust-lang/rust/issues/28728#issuecomment -331460667 및 https://github.com/rust-lang/rust/issues/28728#issuecomment -263956134

@RalfJung 당신은 하이퍼 링크 업데이트 할 수 https://github.com/simnalamburt/snippets/blob/master/rust/src/bin/infinite.rs을 에 문제 설명에 https://github.com/simnalamburt/snippets/blob /12e73f45f3/rust/infinite.rs 이거? 이전 하이퍼 링크는 in이 영구 링크가 아니기 때문에 오랫동안 끊어졌습니다. 감사! 😛

@simnalamburt 완료, 감사합니다!

MIR 옵트 수준을 높이면 다음과 같은 경우에 최적화 오류를 방지 할 수 있습니다.

pub fn main() {
   (|| loop {})()
}

--emit=llvm-ir -C opt-level=1

define void @_ZN7example4main17hf7943ea78b0ea0b0E() unnamed_addr #0 !dbg !6 {
  unreachable
}

--emit=llvm-ir -C opt-level=1 -Z mir-opt-level=2

define void @_ZN7example4main17hf7943ea78b0ea0b0E() unnamed_addr #0 !dbg !6 {
  br label %bb1, !dbg !10

bb1:                                              ; preds = %bb1, %start
  br label %bb1, !dbg !11
}

https://godbolt.org/z/N7VHnj

rustc 1.45.0-nightly (5fd2f06e9 2020-05-31)

pub fn oops() {
   (|| loop {})() 
}

pub fn main() {
   oops()
}

특별한 경우에는 도움이되었지만 일반적으로 문제를 해결하지는 못합니다. https://godbolt.org/z/5hv87d

일반적으로이 문제는 rustc 또는 LLVM이 관련 최적화를 사용하기 전에 순수 함수가 전체임을 증명할 수있는 경우에만 해결 될 수 있습니다.

사실 저는 그것이 문제를 해결했다고 주장하지 않았습니다. 미묘한 효과는 다른 사람들에게 충분히 흥미로워 서 여기서도 언급 할 가치가있는 것 같았습니다. -Z insert-sideeffect 는 계속해서 두 경우를 모두 수정합니다.

LLVM 측에서 뭔가 움직이고 있습니다. 진행률 보장을 제어하기 위해 함수 수준 속성을 추가하라는 제안이 있습니다. https://reviews.llvm.org/D85393

나는 왜 모든 사람들이 (여기와 LLVM 스레드에서) 앞으로 진행에 관한 조항을 강조하는 것처럼 보이는지 잘 모르겠습니다.

루프의 제거는 메모리 모델의 직접적인 결과 인 것 같습니다. 값을 사용하기 전에 발생하는 한 값의 계산을 이동할 수 있습니다. 이제 그 값을 사용할 수 없다는 증거가 있다면 그것은 이전에 일어난 일이 없다는 증거이며 코드는 미래로 무한히 멀어 질 수 있으며 여전히 메모리 모델을 만족합니다.

또는 메모리 모델에 익숙하지 않은 경우 전체 루프가 값을 계산하는 함수로 추상화된다는 것을 고려하십시오. 이제 해당 함수를 호출하여 루프 외부의 모든 값 읽기를 바꿉니다. 이 변환은 확실히 유효합니다. 이제 값을 사용하지 않는 경우 무한 루프를 수행하는 함수 호출이 없습니다.

값의 계산은 값을 사용하기 전에 발생하는 한 이동할 수 있습니다. 이제 그 값을 사용할 수 없다는 증거가 있다면 그것은 이전에 일어난 일이 없다는 증거이며 코드는 미래로 무한히 멀어 질 수 있으며 여전히 메모리 모델을 만족합니다.

이 명령문은 해당 계산이 종료되는 경우에만 정확합니다. 비 종결은 부작용이며, 표준 출력 ( "순수하지 않음")으로 인쇄하는 계산을 제거하지 않는 것처럼 종료되지 않는 계산을 제거 할 수 없습니다.

결과가 사용되지 않더라도 다음 함수 호출을 제거하는 것은 좋지 않습니다.

fn sideeffect() -> u32 {
  println!("Hello!");
  42
}

fn main() {
  let _ = sideffect(); // May not be removed.
}

이것은 모든 종류의 부작용에 해당되며 인쇄를 loop {} 대체 할 때도 마찬가지입니다.

부작용으로서의 비 종결에 대한 주장은 그것이 논란의 여지가 없다는 동의뿐만 아니라 준수해야 할 _ 언제 _에 대한 동의를 요구합니다.

루프가 값을 계산하면 비 종결이 확인됩니다. 루프의 결과에 의존하지 않는 계산의 순서를 변경할 수있는 경우 비 종결이 관찰되지 않습니다.

LLVM 스레드의 예와 같습니다.

x = y % 42;
if y < 0 return 0;
...

분할의 종료 속성은 재정렬과 관련이 없습니다. 최신 CPU는 성공적인 분기의 분할, 비교, 분기 예측 및 프리 페치를 병렬로 실행하려고 시도합니다. 따라서 y 가 음수이면 반환 된 0 를 관찰 할 때 완료된 나눗셈을 관찰 할 수 없습니다. (여기서 "관찰"한다는 것은 프로그램이 아니라 CPU가있는 오실로스코프로 측정하는 것을 의미합니다)

분할이 완료된 것을 볼 수 없으면 분할이 시작되는 것을 볼 수 없습니다. 따라서 위 예제의 분할은 일반적으로 재정렬이 허용되며 컴파일러가 수행 할 수있는 작업입니다.

if y < 0 return 0;
x = y % 42;
...

나는 이것이 허용되지 않는 언어가있을 수 있기 때문에 "보통"이라고 말합니다. Rust가 그런 언어인지 모르겠습니다.

순수 루프도 다르지 않습니다.

나는 그것이 문제가 아니라고 말하는 것이 아닙니다. 전진 보장은 그것이 일어나도록하는 것이 아니라고 말할뿐입니다.

부작용으로서의 해지 불능에 대한 주장은 그것이 논란의 여지가 없다는 합의뿐만 아니라 그것이 언제 관찰되어야하는지에 대한 합의를 요구합니다.

내가 표현하고있는 것은 프로그래밍 언어와 컴파일러의 전체 연구 분야의 합의입니다. 물론 동의하지 않아도되지만 "컴파일러 정확성"과 같은 용어를 다시 정의하는 것이 좋습니다. 다른 사람과의 토론에는 도움이되지 않습니다.

허용되는 관찰은 항상 소스 레벨에서 정의됩니다. 언어 사양은 "추상 기계"를 정의합니다. 이것은 프로그램의 허용되는 관찰 가능한 동작이 무엇인지 (이상적으로는 수학적 세부 사항으로) 설명합니다. 이 문서에서는 최적화에 대해 설명하지 않습니다.

그런 다음 컴파일러가 생성하는 프로그램이 소스 프로그램이 가질 수 있다고 명시한 관찰 가능한 동작 만 나타내는 지 여부에서 컴파일러의 정확성을 측정합니다. 이것이 정확성을 중요하게 생각하는 모든 프로그래밍 언어가 작동하는 방식이며 컴파일러가 정확할 때 정확한 방식으로 캡처하는 방법을 아는 유일한 방법입니다.

각 언어는 소스 수준에서 정확히 관찰 할 수있는 것으로 간주되는 것과 소스 동작이 "정의되지 않은"것으로 간주되어 컴파일러에서 발생하지 않는 것으로 간주 할 수있는 것을 정의하는 것입니다. 이 문제는 C ++에서 다른 부작용이없는 무한 루프 ( "사일런트 디버전스")가 정의되지 않은 동작이라고 말하지만 Rust는 그런 말을하지 않기 때문에 발생합니다. 이것은 Rust에서 비 종결이 항상 관찰 가능하며 컴파일러에 의해 보존되어야 함을 의미합니다. 대부분의 프로그래밍 언어는이 선택을합니다. C ++를 선택하면 실수로 프로그램에 정의되지 않은 동작 (및 심각한 버그)을 도입하기가 매우 쉽습니다. Rust는 안전 코드에서 정의되지 않은 동작이 발생하지 않는다고 약속하고, 안전 코드는 무한 루프를 포함 할 수 있기 때문에 Rust의 무한 루프는 동작을 정의해야합니다 (따라서 보존되어야합니다).

이러한 것들이 혼란 스러우면 배경 자료를 읽는 것이 좋습니다. Benjamin Pierce의 "Types and Programming Languages"를 추천 할 수 있습니다. 작성자가 실제로 얼마나 잘 알고 있는지 판단하기 어려울 수 있지만 많은 블로그 게시물을 찾을 수도 있습니다.

구체적으로, 부서 예가 다음과 같이 변경된 경우

x = 42 % y;
if y <= 0 { return 0; }

그런 다음 조건부 _cannot_이 나눗셈 위에 올릴 수 있다는 데 동의하기를 바랍니다. 왜냐하면 y가 0 일 때 관찰 가능한 동작을 변경하기 때문입니다 (충돌에서 0을 반환).

같은 방식으로

x = if y == 0 { loop {} } else { y % 42 };
if y < 0 { return 0; }

Rust 추상 기계는 이것을 다음과 같이 다시 작성할 수 있습니다.

if y == 0 { loop {} }
else if y < 0 { return 0; }
x = y % 42;

그러나 첫 번째 조건과 루프는 버릴 수 없습니다.

랄프, 나는 당신이하는 일의 절반을 아는 척하지 않고 새로운 의미를 도입하고 싶지 않습니다. 나는 정확성이 무엇인지에 대한 정의에 전적으로 동의합니다 (실행 순서는 프로그램 순서와 일치해야합니다). 비 종결이 관찰 될 수있는 "언제"가 일부라고 생각했습니다. 루프 결과를보고 있지 않으면 종결에 대한 증인이 없습니다 (따라서 부정확성을 주장 할 수 없습니다). . 실행 모델을 다시 검토해야합니다.

나와 함께 해주셔서 감사합니다

@zackw 감사합니다. 그것은 다른 코드이며, 물론 다른 최적화를 가져옵니다.

루프가 분할과 동일한 방식으로 최적화된다는 내 전제는 결함이 있었기 때문에 (나눗셈의 결과를 볼 수 없습니다 == 루프가 종료되는 것을 볼 수 없습니다) 나머지는 중요하지 않습니다.

@olotenko "루프 결과보기"가 무슨 뜻인지 모르겠습니다. 비 종료 루프는 전체 프로그램을 분기시켜 관찰 가능한 동작 으로 간주합니다. 즉, 프로그램 외부 에서 관찰 할 수 있다는 의미입니다. 에서와 같이 사용자는 프로그램을 실행하고 영원히 계속되는 것을 볼 수 있습니다. 영원히 계속되는 프로그램은 사용자가 프로그램에 대해 관찰 할 수있는 내용을 변경하기 때문에 종료되는 프로그램으로 컴파일되지 않을 수 있습니다.

루프가 무엇을 계산했는지 또는 루프의 "반환 값"이 사용되었는지 여부는 중요하지 않습니다. 중요한 것은 사용자가 프로그램을 실행할 때 관찰 할 수있는 것입니다. 컴파일러는이 관찰 가능한 동작이 동일하게 유지되는지 확인해야합니다. 비 종결은 관찰 가능한 것으로 간주됩니다.

다른 예를 들자면 :

fn main() {
  loop {}
  println!("Hello");
}

이 프로그램은 루프 때문에 아무것도 인쇄하지 않습니다. 그러나 루프를 최적화하면 (또는 인쇄로 루프를 재정렬하면) 갑자기 프로그램이 "Hello"를 인쇄합니다. 따라서 이러한 최적화는 프로그램의 관찰 가능한 동작을 변경하고 허용되지 않습니다.

@RalfJung 괜찮아, 이제 알았다. 내 원래 문제는 여기서 "전진 진행 보장"이 어떤 역할을 하는가였습니다. 최적화는 전적으로 데이터 의존성에서 가능합니다. 내 실수는 실제로 데이터 종속성이 프로그램 순서의 일부가 아니라는 것입니다. 말 그대로 언어 의미에 따라 완전히 정렬 된 표현식입니다. 프로그램 순서가 총계라면, 앞으로 진행 보장 ( "프로그램 순서의 모든 하위 경로가 유한하다"라고 다시 언급 할 수 있음)없이 우리는 (실행 순서에서) 종료로 _prove_ 할 수있는 표현식 만 재정렬 할 수 있습니다. 동기화 작업, OS 호출, IO 등의 관찰 가능성과 같은 몇 가지 다른 속성을 보존합니다.

그것에 대해 좀 더 생각해볼 필요가 있지만, x = y % 42 예제에서 분할이 발생한 것처럼 "인식"할 수있는 이유를 알 수 있다고 생각합니다. 일부 입력에 대해 실제로 실행되지는 않더라도 동일한 것이 임의의 루프에 적용되지 않는 이유. 전체 (프로그램) 순서와 부분 (실행) 순서의 대응 관계의 미묘함을 의미합니다.

무한 재귀가 스택 오버플로 크래시 ( "사용자가 결과를 관찰하는"의미에서 "종료")로 끝날 것이기 때문에 "관찰 가능한 동작"이 그보다 조금 더 미묘 할 수 있다고 생각합니다. 그러나 꼬리 호출 최적화 종료되지 않는 루프로 바뀝니다. 적어도 이것은 Rust / LLVM이 할 다른 일입니다. 그러나 우리는 그 질문이 실제로 내 문제에 관한 것이 아니기 때문에 논의 할 필요가 없습니다.

스택 오버플로

스택 오버플로는 실제로 모델링하기 어렵습니다. 좋은 질문입니다. 메모리 부족 상황에서도 동일합니다. 첫 번째 근사치로서 우리는 공식적으로 이런 일이 발생하지 않는 척합니다. 이것은 각 호출에 만든 비 결정적 선택 - 더 좋은 방법은 함수를 호출 언제든지, 당신으로 인해 스택 오버플로 오류가 발생할 수

종료로 증명할 수있는 표현식 만 (실행 순서로) 재정렬 할 수 있습니다.

과연. 더 많은 사람들은 "순수"해야합니다. 즉, 부작용이 없어야합니다. println! 두 개를 다시 주문할 수 없습니다. 이것이 우리가 보통 비 종결도 효과로 간주하는 이유입니다. 왜냐하면이 모든 것이 "순수한 표현은 재정렬 될 수 있습니다"와 "종결하지 않는 표현은 불순합니다"(순수 = 부작용이 있음)로 축소되기 때문입니다.

Divison은 잠재적으로 불순하지만 0으로 나눈 경우에만 패닉, 즉 제어 효과가 발생합니다. 이것은 직접적으로 관찰 할 수있는 것이 아니라 간접적으로 (예를 들어 패닉 핸들러가 무언가를 stdout에 출력하게함으로써 관찰 가능하게합니다). 따라서 나눗셈은 0으로 나눈 것이 아니라고 확신하는 경우에만 재정렬 될 수 있습니다.

이 문제라고 생각하는 데모 코드가 있지만 완전히 확실하지 않습니다. 필요한 경우 새 버그 보고서에 넣을 수 있습니다.
https://github.com/uglyoldbob/rust_demo 의 git repo에 코드를 넣었습니다.

내 무한 루프 (부작용 포함)가 최적화되고 트랩 명령이 생성됩니다.

그것이이 문제의 사례인지 다른 것인지는 모르겠습니다. 임베디드 장치는 제 전문 분야가 아니며 이러한 모든 외부 크레이트 종속성으로 인해 코드가 다른 일을하는지 전혀 모릅니다. ^^하지만 귀하의 프로그램은 안전하지 그리고 내가 그것을 별도의 문제라고 말하고 싶지만, 그래서 루프의 휘발성 액세스를 가지고있다. 귀하의 예제를 놀이터에 넣었을 때 올바르게 컴파일되었다고 생각하므로 문제가 추가 종속성 중 하나에 있다고 생각합니다.

루프의 모든 것이 지역 변수에 대한 참조 인 것 같습니다 (다른 스레드로 이스케이프되지 않음). 이러한 상황에서 휘발성 저장소가없고 관찰 가능한 효과가 없음을 쉽게 증명할 수 있습니다 (동기화 할 수있는 저장소 없음). Rust가 휘발성에 특별한 의미를 추가하지 않으면이 루프는 순수한 무한 루프로 줄일 수 있습니다.

@uglyoldbob llvm-objdump 이 눈에 띄게 도움이되지 않고 부정확하지 않은 경우 예제에서 실제로 일어나는 일이 더 명확 해집니다. 여기서 bl #4 (실제로 유효한 어셈블리 구문이 아님)은 bl 명령어가 끝난 후 4 바이트로 분기하는 것을 의미합니다. 즉, main 함수의 끝입니다. 다음 기능의 시작. 다음 함수는 (내가 빌드 할 때) _ZN11broken_loop18__cortex_m_rt_main17hbe300c9f0053d54dE 호출되며 이것이 실제 main 함수입니다. 변형되지 않은 이름 main 의 함수는 사용자의 함수가 아니지만 cortex-m-rt 제공하는 #[entry] 매크로에 의해 생성 된 완전히 다른 함수입니다. 귀하의 코드는 실제로 최적화되지 않습니다. (사실 디버그 모드에서 빌드하기 때문에 최적화 프로그램이 실행되지 않습니다.)