Fix fastmath for vararg +, *, min, max methods #54513
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
I don't think checking what instructions llvm decides to use makes sense for checking fastmath is applying correctly.
|
This seems clearly good to me. I think n-arg parsing has shown to be a failure but unfortunately it seems to broken to change it now (#48849). |
kimikage
reviewed
May 30, 2024
Comment on lines
+288
to
+289
| $op_fast(a::Number, b::Number, c::Number, xs::Number...) = | ||
| $op_fast(promote(x,y,c,xs...)...) |
There was a problem hiding this comment.
a, b, c != x, y, c 😱
There was a problem hiding this comment.
Nice catch, indicates some missing coverage as well.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Currently using the fastmath vararg +, *, min, max methods only actually sets fastmath if they are specifically overloaded even when the correct 2 argument methods have been defined.
As such,
ComplexF32, ComplexF64do not currently set fastmath when using the vararg methods. This will also fix any other types, such as those in SIMD.jl, which don't overload the vararg methods.E.g.
now works correctly.
I see no reason why the vararg methods shouldn't default to using the fastmath 2 argument methods instead of the non fastmath ones, which is the current behaviour.
I also switched the implementation to use
afoldlas that's what the non fastmath vararg methods use.Fixes #54456 and eschnett/SIMD.jl#108.