Profile guided trimming

[jnyrup]

The current efforts around trimming seems to be about ensuring safe trimming, i.e. no reachable code is removed.
I was wondering whether a kind of unsafe opt-in trimming would be interesting for .net.
Like PGO uses profile data to determine hot paths, Profile Guided Trimming would use profile data to narrow down the scope of trimmable code from reachable to reached code.

This brings along some open questions.

• how much effect would it have?
• what happens if a path not included in the profile data is followed in the trimmed IL, e.g. exception handling.

[danmoseley]

Could you say more about what you would be trying to achieve?

[EgorBo]

E.g. here is the existing workflow we have for PGO (not-tiered one):

# build our app
dotnet build -c Release

# have a test run & collect profile data
dotnet-trace collect .... bin\Release\myapp.exe

# extract PGO data from traces to a separate file
dotnet-pgo create-mibc --trace trace.nettrace --output pgo.mibc

# Consume PGO data when we publish a retail version of the app
dotnet publish -c Release -r win-x64 /p:ReadyToRunOptimizationData=pgo.mibc /p:PublishTrimmed=true

So I guess ILLink could use pgo.mibc file here

PS: CoreCLR runtime only

[stephentoub]

You would have to have a lot of confidence that the scenario profiled exercised every required code path. If the linker trimmed everything else away, and it turned out some of that code was required for some executions, the app could break in a multitude of ways.

[EgorBo]

You would have to have a lot of confidence that the scenario profiled exercised every required code path. If the linker trimmed everything else away, and it turned out some of that code was required for some executions, the app could break in a multitude of ways.

The idea is - let's say I have a huge app and I want to try ILLink feature - currently I have to:

1. rebuild my app with ILLink enabled
2. run tests
3. any missing methods/types? update ILLink config
4. goto step 1 until no issues found

a quick run with PGO-like approach can save me a lot of time by generating an initial list of exceptions.

[stephentoub]

I don't think trial and error is the recommended flow :-) Rather, it would be to turn on the linker and go through all the warnings, addressing each.

I also didn't think that was what the OP was asking about, but I could be wrong.

[jnyrup]

@danmoseley I was playing around with IL trimming for a toy project to see how much the binary size could be trimmed.

ConsoleApp

class Program
{
    static int Main() => ExternalClass.Foo(fast: true);
}

ExternalLibrary

public static class ExternalClass
{
    public static int Foo(bool fast)
    {
        if (fast)
            return 0;

        return ExpensiveCalculation();
    }

    private static int ExpensiveCalculation()
    {
        // some code that uses Linq.
        return Enumerable.Range(0, 42).First();
    }
}

In the example above Range and First from Linq are reachable from Main and hence System.Linq.dll is not (completely) trimmed away.
As Foo is always called with fast: true I wondered if IL trimming could be made more aggressive, as the reachability graph here is an over-estimation of what code is actually reached during execution.
(Remember it's a toy example, so ignore that I could duplicate parts of Foo into FooFast from which Linq is not reachable)

My idea is that profiling data could be used to adjust the reachability graph.
Both to prune off non-reached code (over-estimations) and as @EgorBo points out reached code that was not part of the statically reachable code (under-estimations).
As @stephentoub points out about the over-estimations, one would need to have a lot of confidence in the profile data.

If it's relevant I was using 6.0.100-preview.2.21155.3 for my experiments.