You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This patch introduces significant changes to how device code split
detects functions and global variables which should be included into a
cloned module.
There are two main changes done to that:
1. analysis algorithm now traces uses of global variables to allow
adding all globals into every split module
2. analysis algorithm now traces indirect calls, trying to define a list
of all functions which are potentially called indirectly to avoid the
need to disabled device code split completely in presence of indirect
calls
Both things are implemented through new `DependencyGraph` entity, which
replaces `CallGraph` entity we used.
Instead of calls, that new graph is built over _uses_ of functions and
variables to understand which functions and global variables are used by
which functions and global variables.
The most tricky part here is indirect calls: we can't understand which
exact function is being called by an indirect call. However, we can
compile a list of _potentially_-called function by comparing function
signatures with signature of an indirect call.
On top of that, ESIMD handling is refactored by this patch:
- outlined ESIMD-specific handling into a separate function
- created new ESIMD-specific device code split helper
New ESIMD-specific device code split helper is needed, because we should
use different rules for ESIMD and non-ESIMD parts of a module when
splitting it to two. For ESIMD part we want to grab all ESIMD-functions
even if they were not considered as entry points in the original module.
For non-ESIMD part we **don't want** to grab _any_ ESIMD-functions, even
if they are referenced/used by non-ESIMD functions.
Both of those special rules come from `invoke_simd` feature support:
non-ESIMD kernel can indirectly reference a ESIMD function. Since those
different kind of functions require different processing, we have to
completely separate them before processing step. Non-ESIMD module could
be incomplete as a result of such split, but it will be merged back with
ESIMD module after ESIMD lowering. That merge step is required for
`invoke_simd` functionality.
---------
Co-authored-by: Cai, Justin <[email protected]>
0 commit comments