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

Arithmetic domain error on perfectly fine code with LLVM-Backend #1606

Open
spreadLink opened this issue May 24, 2024 · 3 comments
Open

Arithmetic domain error on perfectly fine code with LLVM-Backend #1606

spreadLink opened this issue May 24, 2024 · 3 comments
Assignees

Comments

@spreadLink
Copy link

The following code should be fine according to Dylan semantics, but causes an arithmetic-domain-error:

define constant <v3> = limited(<vector>, of: <single-float>, size: 3);


define function stop-llvm-from-inlining-everything(v :: <v3>) => (v :: <v3>)
  v
end function;

define function run()
  let v = make(<v3>, fill: 0.0);
  v[0] := 1.0;
  v[1] := 2.0;
  v[2] := 3.0;
  stop-llvm-from-inlining-everything(v);
  v[0] := v[1] / 40.0;
  v[1] := v[2] / 40.0;
  v[2] := v[0] / 40.0;
end function;


run();

Presumably this happens due to floating point traps being enabled via feenableexcept, but LLVM assumes they are not.

@cgay
Copy link
Member

cgay commented May 24, 2024

The error occurs on the second assignment to v[1]:
https://play.opendylan.org/shared/e9eb19497771d59e

and doesn't occur when we use doubles everywhere:
https://play.opendylan.org/shared/4bbbb7e7045e1a1c

@spreadLink
Copy link
Author

Yes, it occurs because LLVM believes it can coalesce the last two divisions into a simd packed single division, as that would be legal with the default semantics for C, but isn't a valid transform when the invalid floating point flag is in effect. This SO post also ran into the issue (in C): https://stackoverflow.com/questions/53982412/perfectly-fine-division-throws-floating-point-exception

@housel housel self-assigned this Jun 1, 2024
@housel
Copy link
Member

housel commented Jun 1, 2024

I verified that the issue can be fixed by adding the strictfp attribute to all relevant functions. My llvm library's attribute support is still stuck in 2015, but once this is resolved I'll be able to add it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants