One test was miscategorized as 'fast' because of this issue, but it
would occasionally fail. It turns out it always fails once you ask
for 7 points or more, so let's fix that and move it back to 'slow'.
Fixes rdar://162597936.
- Don't pass 'verify' since it's now the default
- Update tests where diagnostics changed in a correct way to pass 'on' instead
- Delete compiler_scale/explicit_requirements_perf.swift since it's not testing anything with the requirement machine
All other scale-tests are in validation-test, so move this one there
too to speed up non-validation test runs.
Also this fixes the failure on Windows, where we don't run validation
tests yet.
It's likely that these were listed as "REQUIRES: OS=macosx" to not
redundantly run them for iOS et al, but they don't take that long and
so it's more useful for Linux devs to be able to run them locally if
need be. Or to catch something that really is different on non-macOS.
This was causing an exponential amount of time traversing the AST with
deeply chained protocol extension methods, such as in the
TestCodableRouter.swift test in Kitura.
If the OpaqueValueExpr is referenced more than once within the
OpenExistentialExpr it'll still get visited more than once, but that
doesn't seem to happen in practice. If it turns out to be a problem,
we can weaken the assertion I'm adding here.
https://bugs.swift.org/browse/SR-11012
Instead of visiting all members of all types and extensions, bail out
early if the type is not a class or protocol, or the extension is not
extending a class. This means we don't visit structs, enums or
protocol extensions at all, which will avoid delayed parsing.
Also, we were evaluating isObjC() on each member, which is an expensive
operation; if the member does not have an explicit @objc we would still
have to check if it overrides an @objc method or witnesses an @objc
protocol requirement.
Since most members are not ever found by dynamic lookup, this is wasted
work. Instead, let's rely on AnyObject lookup filtering non-@objc
members at the call site, which it was already doing anyway.
Now that SILGen and IRGen can trigger type checking work, we have to run the
full pipeline to get a complete picture.
Thankfully everything still passes!
Since getStoredProperties() is a request that lowers lazy properties
and property wrappers to their underlying storage, and SIL can validate
stored property and enum element types, there's no longer any need for
Sema to explicitly finalize members of structs and enums. SILGen can
trigger any necessary type checkin work just by lowering a struct or
enum type.
Now the only remaining reason we need finalizeDecl() is adding implicit
methods to classes, and synthesizing accessors for storage in classes
and protocols.
This improves on the previous situation:
- The request ensures that the backing storage for lazy properties
and property wrappers gets synthesized first; previously it was
only somewhat guaranteed by callers.
- Instead of returning a range this just returns an ArrayRef,
which simplifies clients.
- Indexing into the ArrayRef is O(1), which addresses some FIXMEs
in the SIL optimizer.
Adds a NumStoredPropertiesQueries stat.
Adds a test case for an increasing number of lazy stored class
properties. Each property requires a formal access within the
initializer. This would manifest as cubic behavior in
AccessEnforcementOpts, which scales as O(1.5) in the above stat.
Parsing collection literal expression used to take exponential time
depending on the nesting level of the first element.
Stop using 'parseList()' because using it complicates libSyntax parsing.
rdar://problem/45221238 / https://bugs.swift.org/browse/SR-9220
rdar://problem/38913395 / https://bugs.swift.org/browse/SR-7283
Adds a stat to SILInstruction's transferNodesFromList to record the
number of times an instruction is transfered to another block. This is
the only way I can think of to detect quadratic behavior of passes
that split basic blocks.
This, somewhat questionably, fits the polynomial model and the
exponential model, and then chooses the one with the best R^2. However,
no matter how statistically valid this is, it works reasonably in
practice.
Slow growing things sometimes get classified as 1.0^n or 1.1^n, but
these are either spurious or not relevant, and so a similar thresholding
to the polynomial fit is used.
For all types, we can safely skip nested nominal types and
typealiases.
For a struct, we only have to look at VarDecls; methods never
affect layout.
Similarly for an enum, only EnumElementDecls matter.
For a class, we still have to look at all methods and properties.
Ideally, in non-optimized builds we would invoke virtual methods
by calling thunks, and only emit the thunks from the translation
unit containing the class. Then the layout of a class will
only be necessary if you subclass the class.
This should improve compiler scalability in multiple-frontend
mode.
