Linker dependency framework #101277
Linker dependency framework #101277
Conversation
jtschuster
added
NO-MERGE
|
Tagging subscribers to this area: @agocke, @MichalStrehovsky, @jkotas |
| protected override void OnMarked (MarkStepNodeFactory context) | ||
| { | ||
| markStep.MarkTypeImpl (reference, reason, origin); | ||
| } |
There was a problem hiding this comment.
I don't know enough of the DF to tell if this is the right place to do the heavy processing. But I guess for now it is.
I assume eventually all of this would move to GetDependencies and we would remove OnMarked, right?
Future thought: Try to figure out how the DF will play with Annotations and the notion of "marked item" which is used outside of the mark step in the trimmer.
There was a problem hiding this comment.
Yeah, I think ideally most of this moves to GetDependencies and this is minimal or removed.
My thought is that eventually the Annotations markings will forward to the analyzer markings, but that could get complicated if marking (not just IsMarked checks) happen outside of MarkStep. In the meantime, I think OnMarked will call Annotations.MarkX.
| @@ -2759,7 +2849,7 @@ void MarkGenericArguments (IGenericInstance instance) | |||
| var argument = arguments[i]; | |||
| var parameter = parameters[i]; | |||
|
|
|||
| TypeDefinition? argumentTypeDef = MarkType (argument, new DependencyInfo (DependencyKind.GenericArgumentType, instance)); | |||
| var argumentTypeDef = MarkTypeImpl (argument, new DependencyInfo (DependencyKind.GenericArgumentType, instance)); | |||
There was a problem hiding this comment.
This is the place where it gets interesting for TypeRef versus TypeDef :-)
…ependencyFramework
…ependencyFramework
jtschuster
removed
NO-MERGE
src/tools/illink/src/linker/Linker.Steps/MarkStep.ProcessCallbackNode.cs
Outdated
Show resolved
Hide resolved
src/tools/illink/src/linker/Linker.Steps/MarkStep.TypeDefinitionNode.cs
Outdated
Show resolved
Hide resolved
src/tools/illink/src/linker/Linker.Steps/MarkStep.TypeIsRelevantToVariantCastingNode.cs
Outdated
Show resolved
Hide resolved
| @@ -2014,9 +2028,21 @@ internal void MarkStaticConstructorVisibleToReflection (TypeDefinition type, in | |||
| if (CheckProcessed (type)) | |||
| return type; | |||
|
|
|||
| if (type.HasMethods) { | |||
There was a problem hiding this comment.
I'm curious why this moved - at first glance it looks like it better belongs in ProcessType since it should happen just once per type definition.
There was a problem hiding this comment.
Originally I moved it up because it relied on the DependencyInfo, but I think that can condition can be removed and moved back to ProcessMethod. I think the check on the DependencyKind was only to prevent infinite recursion when marking cctors, which we won't hit with the dependency analyzer.
| protected override string GetName (NodeFactory context) => $"{type.GetDisplayName()} is relevant to variant casting"; | ||
| protected override void OnMarked (NodeFactory context) | ||
| { | ||
| context.MarkStep.Annotations.MarkRelevantToVariantCasting (type); |
There was a problem hiding this comment.
When do we use OnMarked vs GetStaticDependencies?
There was a problem hiding this comment.
I just used OnMarked arbitrarily for this since there aren't any dependencies. It looks like OnMarked will do work up front when the node is returned from another GetStaticDependencies, then it's added to a stack to later call GetStaticDependencies.
- Rename dependency analyzer - Remove empty lines - Remove methods queue - Move static ctor marking
…ster/runtime into LinkerDependencyFramework
|
Did you try a simple perf measurement? I don't expect to see noticeable difference, but it does change how the main loop works... ;-) |
Yep, it looks like this has about the exact same speed performance. We allocate a bit more for all the |
Recreates the Process() loop in MarkStep with node that depends on a new copy of itself when the loop needs to be rerun. Within the loop, the new Method and Type nodes are added to the dependency framework analyzer as roots when MarkMethod and MarkType are called, which leads to the OnMarked methods to be called, which forwards to the ProcessType/Method method in MarkStep. The dependency analyzer doesn't do anything interesting yet. In a follow-up I'll move dependencies from the MarkX and ProcessX methods to the DependencyNode types. Makes ILCompiler.DependencyAnalysisFramework output path independent of target architecture. Removes TargetArchitecture and TargetOS from ILLink.Tasks project references. --------- Co-authored-by: vitek-karas <10670590+vitek-karas@users.noreply.github.com>
Recreates the Process() loop in MarkStep with node that depends on a new copy of itself when the loop needs to be rerun. Within the loop, the new Method and Type nodes are added to the dependency framework analyzer as roots when MarkMethod and MarkType are called, which leads to the OnMarked methods to be called, which forwards to the ProcessType/Method method in MarkStep. The dependency analyzer doesn't do anything interesting yet. In a follow-up I'll move dependencies from the MarkX and ProcessX methods to the DependencyNode types. Makes ILCompiler.DependencyAnalysisFramework output path independent of target architecture. Removes TargetArchitecture and TargetOS from ILLink.Tasks project references. --------- Co-authored-by: vitek-karas <10670590+vitek-karas@users.noreply.github.com>
Recreates the Process() loop in MarkStep with node that depends on a new copy of itself when the loop needs to be rerun. Within the loop, the new Method and Type nodes are added to the dependency framework analyzer as roots when MarkMethod and MarkType are called, which leads to the OnMarked methods to be called, which forwards to the ProcessType/Method method in MarkStep. The dependency analyzer doesn't do anything interesting yet. In a follow-up I'll move dependencies from the MarkX and ProcessX methods to the DependencyNode types.