Limit needless code gen with nospecialize #13
Conversation
* added @nospecialize to is_static * split each static type into its own file * changed show method of StaticBool to static(true)/static(false)
Codecov Report
@@ Coverage Diff @@
## master #13 +/- ##
=======================================
Coverage 99.70% 99.70%
=======================================
Files 4 6 +2
Lines 339 342 +3
=======================================
+ Hits 338 341 +3
Misses 1 1
Continue to review full report at Codecov.
|
| is_static(@nospecialize(x)) = is_static(typeof(x)) | ||
| is_static(@nospecialize(x::Type{<:StaticInt})) = True() | ||
| is_static(@nospecialize(x::Type{<:StaticBool})) = True() | ||
| is_static(@nospecialize(x::Type{<:StaticSymbol})) = True() | ||
| is_static(@nospecialize(x::Type{<:Val})) = True() | ||
| is_static(@nospecialize(x::Type{<:StaticFloat64})) = True() | ||
| is_static(x::Type{T}) where {T} = False() | ||
|
|
There was a problem hiding this comment.
@timholy , If I want to avoid generating a unique method for every variant of StaticInt is this the right approach or will it kill inference somewhere down the line? I used MethodAnalysis.methodinstances and it seems to avoid make extra methods but I'm never sure with this sort of stuff
There was a problem hiding this comment.
Presumably everything still infers and optimizes fine, because the behavior doesn't actually depend on the particular types?
There was a problem hiding this comment.
That's the goal. I was hoping to start strategically adding these to trait functions so that we can avoid some of the pitfalls of StaticArrays.
2 participants
There was a little reorganization here but this ones essentially about not generating extra code when checking traits using
@nospecialize