私は丸めモード(+ inf、-inf、nearest、またはtruncate)を変更するRust crateを扱っています。 、私はそれが意図したとおりに動作するデバッグモードでコードをコンパイルすると正の無限大に向かって丸めたときどのLLVMパスが浮動小数点最適化を担当していますか?
fn upward() {
let cw: u32 = 0;
unsafe {
asm!("stmxcsr $0;
mov $0, %eax;
or $$0x4000, %eax;
mov %eax, $0;
ldmxcsr $0;"
: "=*m"(&cw)
: "*m"(&cw)
: "{eax}"
);
}
}
は、私は3分の1 0.3333333333337を得る:
丸めモードを変更する機能は、インラインアセンブリを使用して書かれていますリリースモードでコンパイルすると、丸めモードに関係なく同じ結果が得られます。私はこの動作が、LLVMバックエンドが行う最適化によるものだと思います。
この最適化を担当するLLVMパスが分かっていた場合は、現時点で他の回避策が表示されないため、これらを無効にすることができます。
この情報は、LLVMのバージョン(パスの追加と削除が自由です)と、結果的に 'rustc'のバージョンに依存している可能性があります。 'rustc'のどのバージョンを使用していますか?アップグレードの際にこれが壊れてもかまいませんか? –
私は夜通し錆1.10を使用しています。私はそれが壊れても構わない。何が起こっているのか理解できれば、ちょっとした努力をして回避策を講じることができます。 –
いくつかの読書の後、私は、()関数呼び出しの前にdivide命令を動かしているいくつかのスケジューリングパスがあると思います。 (ちょうど推測)、私が間違っている場合は私を修正します。 –