Undefined Behavior: Changing MXCSR to _MM_ROUND_TOWARD_ZERO on x86 and x86_64.

[herabit]

In Rust, modifying the rounding mode in x86 and x86_64 by modifying the MXCSR register (through _mm_setcsr or inline assembly) is considered immediate undefined behavior.

See here for more info.

[Vrixyz]

Thanks for the issue ; I admit I'm not sure how to research "using inline assembly instead".

• Related: Deprecate MXCSR intrinsics rust-lang/stdarch#781

[Lokathor]

The key element of using inline assembly is that you can't ever leave an inline assembly block without restoring MXCSR to the default state, or you hit the same UB problem.

You'd have to do the entire round-toward-zero operation using only inline assembly.

[Vrixyz]

A bit more context: this operation occurs when using enable_flush_to_zero, for example:

rapier/src/pipeline/physics_pipeline.rs

Line 270 in cf77b5b

enable_flush_to_zero!();

This "flush to zero" leads to important performance improvements.

Brainstorming further:

Could the entire round-toward-zero operation can be summarized as a function call, so the assembly would end up quite small (function declaration, arguments prep, function call) ?

[Lokathor]

You cannot leave flush to zero active while executing rust code, it's simply not allowed.

So you can't have functions to toggle the effect on/off, and you also can't have a function that takes a fn pointer to run with flushing set which changes the state and calls back into rust while the state is changed.

This applies equally to all floating point environment settings, though flush to zero is usually the only one people try to change.

[Ralith]

This "flush to zero" leads to important performance improvements.

Can you elaborate on these? From @Lokathor's comments, it sounds like these just aren't available in sound Rust today, and it might be best to do without.