Repository navigation
Fix #6121 - #6123
Fix #6121#6123
Conversation
As title.
This was never possible before numba#5709 - the `CUDAKernel` class that was returned by specializing had no `specialize()` method to call. Before numba#5709 `ForAll.__call__()` avoided re-specialization - we also need to avoid re-specialization again so that is added back in. Addendum: corrected an inaccurate docstring spotted whilst looking at the code.
|
Buildfarm ID: |
Add tests that check you can't specialize for a different types as well as for the same types as the Dispatcher is already specialized for.
This test takes array ordering into account, and uses multiple arguments. Also, the argument types in other tests should have been passed as arguments to specialize(), not as tuples of argument types.
|
|
|
Buildfarm ID: |
stuartarchibald
left a comment
There was a problem hiding this comment.
Thanks for the patch. Fix and tests look good. The main test here is the compile time response from upstream (e.g. cuDF) and whether the build farm is happy. Waiting for confirmation by @gmarkall on the upstream testing.
|
|
|
@stuartarchibald As far as I can tell from testing cuDF and other libraries, the issue appears to be resolved and I can't see that this introduces any new issues. |
Thanks for confirming. This will make 0.51.0. |
Opening this PR to fix #6121 and iterate on it. The problem is that
forallalways returns a newDispatcher, which immediately compiles the specialization. Prior to #5709 being merged, the cache of compilations was used and any previously-compiled kernel could be returned byspecialize. The fix in this branch introduces a cache of specializedDispatcherobjects to work around the issue.