-
-
Notifications
You must be signed in to change notification settings - Fork 5.5k
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
WIP: Give NTuple{N, T} a layout #31681
Conversation
Meant to make this a draft PR. Oh well. |
In the type system, we generally support tuples of the patter Tuple{..., Vararg{T, N}}. However, when it comes to actually allocating these, we expand them out to `Tuple{..., T, T, T, T, T, ...}`. This makes tuples not particularly suitable as the representation for various memory buffers, because the cost of doing various operations on their datatypes is proportional to the number of elements. This attempts to keep them in the Vararg{T, N} form throughout the system, and similarly adding a form of the layout specification that works for repeated trailing arguments. Current status: Various things work, printing a tuple of this sort crashes in interesting places. Inverse normalization (repeated trailing elements to NTuple) not yet implemented.
Note to self. Current issue is the following subtype: |
259bf69
to
05ae3a2
Compare
In preparation for #31681 in particular, but the problem exists on master as well, we just tend to not encounter non-normalized tuple types that often.
In preparation for #31681 in particular, but the problem exists on master as well, we just tend to not encounter non-normalized tuple types that often.
In preparation for #31681 in particular, but the problem exists on master as well, we just tend to not encounter non-normalized tuple types that often.
Would it be possible to extend this distinction to codegen, and be able to irgen both arrays and structs from tuples? This is currently dealt with somewhat automagically: using LLVM
julia> convert(LLVMType, Tuple{Int32, Int32})
[2 x i32]
julia> convert(LLVMType, Tuple{Int32, Int64})
{ i32, i64 }
# idea: only NTuple is passed as an LLVM array
julia> convert(LLVMType, NTuple{2,Int32})
[2 x i32] Ran into this with @jiahao trying to |
Just checking in to see what the timeline for something like this might be? I'm in the process of wrapping a C library which has several structs with large fields declared as inline/fixed-size arrays (e.g. |
The parameters of `sig` are not guaranteed to match the arguments that were passed on method construction, since the type may have been normalized. This will become more pronounced after #31681, but with OpaqueClosure we now have some method whose sig is Tuple{Vararg{Any}}, so we might as well make this change now. Of course, we may want to print OpaqueClosure methods differently in general, but that's a question for another time, once we've worked out exactly what the sig fields of OpaqueClosure methods should look like.
The parameters of `sig` are not guaranteed to match the arguments that were passed on method construction, since the type may have been normalized. This will become more pronounced after #31681, but with OpaqueClosure we now have some method whose sig is Tuple{Vararg{Any}}, so we might as well make this change now. Of course, we may want to print OpaqueClosure methods differently in general, but that's a question for another time, once we've worked out exactly what the sig fields of OpaqueClosure methods should look like.
The parameters of `sig` are not guaranteed to match the arguments that were passed on method construction, since the type may have been normalized. This will become more pronounced after #31681, but with OpaqueClosure we now have some method whose sig is Tuple{Vararg{Any}}, so we might as well make this change now. Of course, we may want to print OpaqueClosure methods differently in general, but that's a question for another time, once we've worked out exactly what the sig fields of OpaqueClosure methods should look like.
The parameters of `sig` are not guaranteed to match the arguments that were passed on method construction, since the type may have been normalized. This will become more pronounced after #31681, but with OpaqueClosure we now have some method whose sig is Tuple{Vararg{Any}}, so we might as well make this change now. Of course, we may want to print OpaqueClosure methods differently in general, but that's a question for another time, once we've worked out exactly what the sig fields of OpaqueClosure methods should look like.
The parameters of `sig` are not guaranteed to match the arguments that were passed on method construction, since the type may have been normalized. This will become more pronounced after JuliaLang#31681, but with OpaqueClosure we now have some method whose sig is Tuple{Vararg{Any}}, so we might as well make this change now. Of course, we may want to print OpaqueClosure methods differently in general, but that's a question for another time, once we've worked out exactly what the sig fields of OpaqueClosure methods should look like.
The parameters of `sig` are not guaranteed to match the arguments that were passed on method construction, since the type may have been normalized. This will become more pronounced after JuliaLang#31681, but with OpaqueClosure we now have some method whose sig is Tuple{Vararg{Any}}, so we might as well make this change now. Of course, we may want to print OpaqueClosure methods differently in general, but that's a question for another time, once we've worked out exactly what the sig fields of OpaqueClosure methods should look like.
Seems heavily conflicted now |
In the type system, we generally support tuples of the patter Tuple{..., Vararg{T, N}}.
However, when it comes to actually allocating these, we expand them out to
Tuple{..., T, T, T, T, T, ...}
. This makes tuples not particularly suitableas the representation for various memory buffers, because the cost of doing various
operations on their datatypes is proportional to the number of elements. This attempts
to keep them in the Vararg{T, N} form throughout the system, and similarly adding
a form of the layout specification that works for repeated trailing arguments.
Current status: Various things work, printing a tuple of this sort crashes in interesting
places. Inverse normalization (repeated trailing elements to NTuple) not yet implemented. Putting up early for feedback on the overall direction, since this involves a lot of tedious changes that I'd rather only do once.