mikros/rust
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
ec2cc761bc
rust/tests/codegen/unchecked-float-casts.rs

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

37 lines
818 B
Rust
Raw Normal View History

Define UB in float-to-int casts to saturate - Round to zero, and representable values cast directly. - `NaN` goes to 0 - Values beyond the limits of the type are saturated to the "nearest value" (essentially rounding to zero, in some sense) in the integral type, so e.g. `f32::INFINITY` would go to `{u,i}N::MAX.`
2020-04-17 20:42:22 -05:00
// This file tests that we don't generate any code for saturation when using the
// unchecked intrinsics.
Saturating casts between integers and floats (both directions). This affects regular code generation as well as constant evaluation in trans, but not the HIR constant evaluator because that one returns an error for overflowing casts and NaN-to-int casts. That error is conservatively correct and we should be careful to not accept more code in constant expressions. The changes to code generation are guarded by a new -Z flag, to be able to evaluate the performance impact. The trans constant evaluation changes are unconditional because they have no run time impact and don't affect type checking either.
2017-10-08 19:14:00 -05:00
Define UB in float-to-int casts to saturate - Round to zero, and representable values cast directly. - `NaN` goes to 0 - Values beyond the limits of the type are saturated to the "nearest value" (essentially rounding to zero, in some sense) in the integral type, so e.g. `f32::INFINITY` would go to `{u,i}N::MAX.`
2020-04-17 20:42:22 -05:00
// compile-flags: -C opt-level=3
Improve codegen for unchecked float casts on wasm This commit improves codegen for unchecked casts on WebAssembly targets to use the singluar `iNN.trunc_fMM_{u,s}` instructions. Previously rustc would codegen a bare `fptosi` and `fptoui` for float casts but for WebAssembly targets the codegen for these instructions is quite large. This large codegen is due to the fact that LLVM can speculate these instructions so the trapping behavior of WebAssembly needs to be protected against in case they're speculated. The change here is to update the codegen for the unchecked cast intrinsics to have a wasm-specific case where they call the appropriate LLVM intrinsic to generate the right wasm instruction. The intrinsic is explicitly opting-in to undefined behavior so a trap here for out-of-bounds inputs on wasm should be acceptable. cc #73591
2020-07-22 16:51:12 -05:00
// ignore-wasm32 the wasm target is tested in `wasm_casts_*`
Saturating casts between integers and floats (both directions). This affects regular code generation as well as constant evaluation in trans, but not the HIR constant evaluator because that one returns an error for overflowing casts and NaN-to-int casts. That error is conservatively correct and we should be careful to not accept more code in constant expressions. The changes to code generation are guarded by a new -Z flag, to be able to evaluate the performance impact. The trans constant evaluation changes are unconditional because they have no run time impact and don't affect type checking either.
2017-10-08 19:14:00 -05:00
#![crate_type = "lib"]
// CHECK-LABEL: @f32_to_u32
#[no_mangle]
pub fn f32_to_u32(x: f32) -> u32 {
// CHECK: fptoui
// CHECK-NOT: fcmp
// CHECK-NOT: icmp
// CHECK-NOT: select
Define UB in float-to-int casts to saturate - Round to zero, and representable values cast directly. - `NaN` goes to 0 - Values beyond the limits of the type are saturated to the "nearest value" (essentially rounding to zero, in some sense) in the integral type, so e.g. `f32::INFINITY` would go to `{u,i}N::MAX.`
2020-04-17 20:42:22 -05:00
unsafe { x.to_int_unchecked() }
Saturating casts between integers and floats (both directions). This affects regular code generation as well as constant evaluation in trans, but not the HIR constant evaluator because that one returns an error for overflowing casts and NaN-to-int casts. That error is conservatively correct and we should be careful to not accept more code in constant expressions. The changes to code generation are guarded by a new -Z flag, to be able to evaluate the performance impact. The trans constant evaluation changes are unconditional because they have no run time impact and don't affect type checking either.
2017-10-08 19:14:00 -05:00
}
// CHECK-LABEL: @f32_to_i32
#[no_mangle]
pub fn f32_to_i32(x: f32) -> i32 {
// CHECK: fptosi
// CHECK-NOT: fcmp
// CHECK-NOT: icmp
// CHECK-NOT: select
Define UB in float-to-int casts to saturate - Round to zero, and representable values cast directly. - `NaN` goes to 0 - Values beyond the limits of the type are saturated to the "nearest value" (essentially rounding to zero, in some sense) in the integral type, so e.g. `f32::INFINITY` would go to `{u,i}N::MAX.`
2020-04-17 20:42:22 -05:00
unsafe { x.to_int_unchecked() }
Saturating casts between integers and floats (both directions). This affects regular code generation as well as constant evaluation in trans, but not the HIR constant evaluator because that one returns an error for overflowing casts and NaN-to-int casts. That error is conservatively correct and we should be careful to not accept more code in constant expressions. The changes to code generation are guarded by a new -Z flag, to be able to evaluate the performance impact. The trans constant evaluation changes are unconditional because they have no run time impact and don't affect type checking either.
2017-10-08 19:14:00 -05:00
}
#[no_mangle]
Make saturating u128 -> f32 casts the default behavior ... rather than being gated by -Z saturating-float-casts. There are several reasons for this: 1. Const eval already implements this behavior. 2. Unlike with float->int casts, this behavior is uncontroversially the right behavior and it is not as performance critical. Thus there is no particular need to make the bug fix for u128->f32 casts opt-in. 3. Having two orthogonal features under one flag is silly, and never should have happened in the first place. 4. Benchmarking float->int casts with the -Z flag should not pick up performance changes due to the u128->f32 casts (assuming there are any). Fixes #41799
2017-11-09 17:24:05 -06:00
pub fn f64_to_u16(x: f64) -> u16 {
// CHECK: fptoui
Saturating casts between integers and floats (both directions). This affects regular code generation as well as constant evaluation in trans, but not the HIR constant evaluator because that one returns an error for overflowing casts and NaN-to-int casts. That error is conservatively correct and we should be careful to not accept more code in constant expressions. The changes to code generation are guarded by a new -Z flag, to be able to evaluate the performance impact. The trans constant evaluation changes are unconditional because they have no run time impact and don't affect type checking either.
2017-10-08 19:14:00 -05:00
// CHECK-NOT: fcmp
// CHECK-NOT: icmp
// CHECK-NOT: select
Define UB in float-to-int casts to saturate - Round to zero, and representable values cast directly. - `NaN` goes to 0 - Values beyond the limits of the type are saturated to the "nearest value" (essentially rounding to zero, in some sense) in the integral type, so e.g. `f32::INFINITY` would go to `{u,i}N::MAX.`
2020-04-17 20:42:22 -05:00
unsafe { x.to_int_unchecked() }
Saturating casts between integers and floats (both directions). This affects regular code generation as well as constant evaluation in trans, but not the HIR constant evaluator because that one returns an error for overflowing casts and NaN-to-int casts. That error is conservatively correct and we should be careful to not accept more code in constant expressions. The changes to code generation are guarded by a new -Z flag, to be able to evaluate the performance impact. The trans constant evaluation changes are unconditional because they have no run time impact and don't affect type checking either.
2017-10-08 19:14:00 -05:00
}
Reference in New Issue Copy Permalink