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

@nospecialize for identity #44929

Merged
merged 1 commit into from
Apr 11, 2022
Merged

@nospecialize for identity #44929

merged 1 commit into from
Apr 11, 2022

Conversation

Tokazama
Copy link
Contributor

No description provided.

Copy link
Member

@aviatesk aviatesk left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We generally don't need to add @nospecialize annotation if a generic function only contains a single method (and identity will rarely be extended), but approved nevertheless as it doesn't hurt anything anyway.

@Tokazama
Copy link
Contributor Author

I know there's a point where specialization doesn't occur, but I figure that we never wanted it to specialize and that even this was more than we wanted:

julia> using MethodAnalysis

julia> using StaticArrays

julia> length(methodinstances(identity))
18

julia> identity(SVector(1, 2, 3));

julia> length(methodinstances(identity))
19

julia> foo(x) = identity(x)
foo (generic function with 1 method)

julia> foo(SVector(1, 2, 3, 4));

julia> length(methodinstances(identity))
20

@aviatesk
Copy link
Member

Please note that @nospecialize influences dispatch only, does not intervene into inference in anyway. See #41931 for more explanation.

@Tokazama
Copy link
Contributor Author

The goal here was just to avoid codegen. I'm assuming that if this made it so we couldn't even infer what type identity returned that it would be a bad idea.

@aviatesk
Copy link
Member

"codegen" would be avoided even as is assuming the method body of identity is inlined always.

@Tokazama
Copy link
Contributor Author

I was considering additional method instances code generation (which I can see being considered an overgeneralization). Wouldn't we want to avoid generating those addition methods?

@aviatesk
Copy link
Member

It's simply that that information was used for Julia-level inference but it doesn't necessarily imply whole codegen process.

@Tokazama
Copy link
Contributor Author

Gotcha. Thanks for the clarification.

@vtjnash vtjnash merged commit 1fe7cfa into JuliaLang:master Apr 11, 2022
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

Successfully merging this pull request may close these issues.

3 participants