Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Possible inlining bug #45

Open
schell opened this issue Nov 2, 2024 · 0 comments
Open

Possible inlining bug #45

schell opened this issue Nov 2, 2024 · 0 comments
Labels
bug Something isn't working performance

Comments

@schell
Copy link
Contributor

schell commented Nov 2, 2024

It seems that this function has different results depending on whether or not #[inline(always)] is used:

/// Return `1.0` when `value` is less than or equal to `edge`
/// and `0.0` when `value` is greater than `edge`.
#[inline(always)]
pub fn step_le(value: f32, edge: f32) -> f32 {
    ((value <= edge) as u32) as f32
}

I have a shader you can see here that uses this function.

Expected Behaviour

Using ((sphere_aabb.max.z <= 1.0) as u32) as f32, which is a manual inlining of the body of the function, produces the expected results.

Using crate::math::step_le(sphere_aabb.max.z, 1.0) while having an #[inline(always)] annotation on step_le produces the expected results.

Using crate::math::step_le(sphere_aabb.max.z, 1.0) without having an #[inline(always)] annotation on step_le produces the opposite of the expected result.

Example & Steps To Reproduce

I can work on a minimal reproducible shader.

@LegNeato LegNeato added bug Something isn't working performance labels Nov 8, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working performance
Projects
None yet
Development

No branches or pull requests

2 participants