compute deferred dependencies in fasta

[sigmundch]

(this is summarizing some of the discussion I had with @peter-ahe-google this week)

The deferred loading splitting algorithm in dart2js requires 2 pieces of information:

• direct dependencies between entities
• deferred dependencies between entities

We derive the former directly from the AST, but the latter is today computed using some backward reverse engineering: we look at library dependencies, compute the export scopes, and then try to match which direct dependencies would have gone through a deferred import (see https://github.com/dart-lang/sdk/blob/master/pkg/compiler/lib/src/kernel/deferred_load.dart#L23)

This computation is inefficient and redundant with work the CFE already did while resolving the program.

We would like this information to be encoded in the IR in a way that is stable and easy to extract. For example, today the representation of the CheckLibraryIsLoaded is separate from the access and it doesn't indicate which access it is protecting. We did so by design to allow kernel transformations to optimize checks away (e.g hoist them and share them).

My preference is to not derive this information from implicit invariants in the IR. Instead, I propose that we encode the information as data on members or metadata stored on the side. The data we need is basically for each method/initializer, which references to other static methods and constructors are deferred and what deferred prefix/import was used to reach it.

[sigmundch]

For reference, I measured recently and it appears that on a large app our entire deferred-loading algorithm takes 32s, of which 18s are used in the hacky reversed engineered step described above.

[sigmundch]

update to document where we are at.

I looked more into what changes we need to do in dart2js, and I've changed my mind on the strategy to get closer to our end goal here.

Our changes would be very similar if we tried to extract the data from the implicit invariant of CheckLIbraryIsLoaded in the IR, than it will be once we introduce the metadata explicitly. Because at this point we will not be investing in kernel transformations to hoist checks, we'll be using an implementation that derives data directly from the IR tree. This will let us get rid of the hack to compute export scopes, which is also way more expensive as mentioned above.

I'll be sending a CL shortly that seems to be working well.

I believe we don't needs this bug open anymore. Pending work includes:

• addressing an IR representation issue ensure CheckLibraryIsLoaded guards the left-most immediate expression #35320
• address semantic issues in dart2js due to inferred types inferred types not treated the same as explicit type by deferred loading #35311
• evaluating whether to represent deferred types explicitly in the IR in the future (mostly to assist in providing hints to users depending on the direction we take with inferred types not treated the same as explicit type by deferred loading #35311 )