[ILLink] Should the trim analyzer use full dataflow analysis, or single assignment of DAM

Start by reading the DAM analyzer discussion and comparing the proposed full dataflow, first-assignment, and inferred-requirement approaches. Check how illink and ilc would need to match the selected behavior; done means choosing and documenting a consistent analysis model, including branching assignments and warning behavior.

Currently the DAM analyzer does full backwards-branching dataflow analysis for tracking DAM values. This gives it the best analysis (sometimes better than illink), but it does require significant complexity, and can lead to performance issues. Adding matching dataflow analysis to the linker for matching behavior would create similar problems in the linker.

An alternative discussed was to have each local assume the annotation of the first value assigned to it, and warn if a different annotation is assigned to it, much like type analysis in the C# language. This would simplify implementation, but would require workarounds by code expecting to be able to assign differently annotated values to the same local.

We also run into potential issues when a local is first assigned in if/else blocks, a ternary statement, or a switch. We could work around this by taking the Meet of the potential values, or warning if all assignments to a local do not have the same DAM annotations.

Another way to look at it is to assign the requirements on the local variable (determine by assignments where the local is the source and an annotated location is the target), and require that all assignments to that local meet that requirement. This also makes the behavior of local variables analogous to properly annotated fields. Fields must be annotated with the union of the requirements of all the locations that are targets of assignments from the field, while locals would have those annotations inferred.

For example, consider the warning behavior between assuming first assignment

// okay
var myLocal = MyMethodReturnsWithPublicMethods();
myFieldWithPublicMethods = myLocal;

// warn: myLocal requires PublicFields
myLocal = MyMethodReturnsWithPublicFields;
myFieldWithPublicFields = myLocal;

vs. assuming the union of all requirements

// warn: myLocal requires both PublicFields and PublicMethods
var myLocal = MyMethodReturnsWithPublicMethods();
myFieldWithPublicMethods = myLocal;

// okay
myLocal = MyMethodReturnsWithPublicFieldsAndPublicMethods();
myFieldWithPublicFields = myLocal;

Regardless, if we do change the analyzer behavior to either of these, it's likely that illink and ilc will also need to match it for consistency in warnings. This would be a significant regression in the ergonomics of making code trim-safe, but it would greatly simplify analysis and likely increase the speed of the tools.

cc. @dotnet/illink @dotnet/ilc-contrib for discussion