When we first call a python function 'f' with a specific set of arguments, we may not know its return type the first time we try to convert it. To ensure we have a stable typing graph, we repeatedly update the active functions in our graph until the type graph is stable.
This can lead to many copies of the same function, or even multiple signatures of the same function, only one of which we'll use.
This change prunes those away before we submit them to the LLVM layer.
How Has This Been Tested?
Running test_dispatch_to_function_overload with TP_COMPILER_VERBOSE=1with and without this commit causes 13 functions to be converted rather than 17, with a slight speedup.
Types of changes
[ ] Bug fix (non-breaking change which fixes an issue)
[x] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)
Checklist:
[x] My code follows the code style of this project.
[ ] My change requires a change to the documentation.
(by @braxtonmckee)
Motivation and Context
When we first call a python function 'f' with a specific set of arguments, we may not know its return type the first time we try to convert it. To ensure we have a stable typing graph, we repeatedly update the active functions in our graph until the type graph is stable.
This can lead to many copies of the same function, or even multiple signatures of the same function, only one of which we'll use.
This change prunes those away before we submit them to the LLVM layer.
How Has This Been Tested?
Running
test_dispatch_to_function_overloadwithTP_COMPILER_VERBOSE=1with and without this commit causes 13 functions to be converted rather than 17, with a slight speedup.Types of changes
Checklist: