Use a main entry-point instead of a null
SILDeclRef. Eventually we'll want to unify the
emission here such that we visit all the
TopLevelDecls in one shot (and just use a single
profiler), but for now we can just hand the
SILProfiler the expected SILDeclRef.
Use a BumpPtrAllocator instead of a linked list,
and allocate internally within the CounterExpr so
we can just pass about values instead of pointers
and references. This allows us to eliminate
`CounterExpr::Ref`.
Unfortunately this means we can no longer store
CounterExprs in the SourceMappingRegions for
nodes, as we were previously using pointers to
propagate updates the counters made after the
region was popped. Instead we now have to query
the `CounterMap`. But IMO this is a worthwhile
tradeoff for code that's easier to reason about.
So far, function effects only included escape effects.
This change adds side-effects (but they are not computed, yet).
It also involves refactoring of the existing escape effects.
Also the SIL effect syntax changed a bit. Details are in docs/SIL.rst
to SILBuilder::createUncheckedForwardingCast
It would be disastrous to confuse this utility with a bit cast. A bit
cast always produces an Unowned value which must immediately be copied
to be used. This utility always forwards ownership. It cannot be used
to truncate values.
Also, be careful not to convert "reinterpret cast"
(e.g. Builtin.reinterpretCast) into a "value cast" since ownership
will be incorrect and the reinterpreted types might not have
equivalent layout.
This makes it impossible for OSSA utilities to reason about the
lifetime of the value being cast. This fixes bugs in which SILGen
generates bitwise casts without protecting that lifetime.
Fixes rdar://100527903 (Overrelease of optional closure when using
shorthand syntax)
The previous OSSA strategy was to gradually eliminate all "pointer
escape" SIL patterns. That would define away a class of bugs in the
OSSA utilities themselves. This was not friendly to developers working
on SILGen, and we still don't have verification that can catch these
bugs.
The new strategy is to make all OSSA utilities aware of pointer
escapes. This acknowledges reality that SIL is imperfect. Instead,
optimizer support for transforming SIL always needs to recognize
potentially dangerous patterns.
The downside of this new strategy is that it hides performance
problems because SIL optimizations can give up whenever they happen to
see a "pointer escape". We need to keep working on this problem
without being motivated by miscompiling code.
It seems like this defensive logic was written
back when we could create SILProfilers for
declarations in addition to definitions. Now we
should only ever create SILProfilers for
definitions, so we can assert that we always have
a function body available.
This replaces some of the existing checks, and
ensures that we don't emit coverage maps for
property wrapper backing initializers that don't
contain user code.
rdar://99931619
Previously we would delay the emission of
lazy variable getters and stored property
initializers for property wrapper backing storage.
This could lead to their definitions being dropped
if unused, meaning that we wouldn't run the
mandatory diagnostics passes over them.
Fix the logic such that we consider such cases as
having user-written code, and account for a couple
of cases where we can delay emission where we
didn't previously. There are more cases we can
handle here, but I'm leaving that as future work
for now, as `emitOrDelayFunction` is currently
only used for a handful of SILDeclRef kinds.
This is a source breaking change, but only for
invalid (albeit unused) code.
rdar://99962285
This lets us write optimizer unit tests and selectively debug the
optimizer in general. We'll be able trace analyses and control
optimization selectively for certain values.
Adding a trace flag to debug_value is the easiest way to start using
it experimentally and develop the rest of the infrastructure. If this
takes off, then we can consider a new `trace_value`
instruction. For now, reusing debug_value is the least intrusive way to
start writing liveness unit tests.
It makes no sense to operate on the block's instruction list without
also including SILBasicBlock.h anyway. Similarly, it doesn't make
sense to query the entry block without including SILFunction.h.
Now we can call these simple getters in critical-path loops assuming
they are as cheap as a load. I was avoiding calling these in critical
path code, which resulted in less readability and consistency across
the code base.
* [SILOptimizer] Add prespecialization for arbitray reference types
* Fix benchmark Package.swift
* Move SimpleArray to utils
* Fix multiple indirect result case
* Remove leftover code from previous attempt
* Fix test after rebase
* Move code to compute type replacements to SpecializedFunction
* Fix ownership when OSSA is enabled
* Fixes after rebase
* Changes after rebasing
* Add feature flag for layout pre-specialization
* Fix pre_specialize-macos.swift
* Add compiler flag to benchmark build
* Fix benchmark SwiftPM flags
Specifically, we get an additional table like thing called sil_moveonlydeinit. It looks as follows:
sil_moveonlydeinit TYPE {
@FUNC_NAME
}
It always has a single entry.
This allows one to know that the type is for a first class move only type and
not a move only wrapped type.
Previously, I did this by checking type.isMoveOnly() &&
!type.isMoveOnlyWrapped(). Better to just have a helper that semantically does
this rather than using a code pattern that doesn't semantically say what it
actually does unless one knows the intent.
Currently the SROA just overwrites already-existing expressions on
variables. When SROA is recursively run on a data structure this leads to
nonsensical expressions such as
type $*Outer, expr op_fragment:#Inner.x
instead of
type $*Outer, expr op_fragment:#Outer.inner op_fragment:#Inner.x
The (nonsensical) LLVM IR generated from this violates some assumptions in LLVM
for example, if a struct has multiple members of the same type, you can end up
with multiple dbg.declare intrinsics claiming to describe the same variable). As
a quick fix, this patch detects this situation and drops the debug info. A
proper fix shouldn't be too difficult to implement though.
rdar://99874371
The function type's generic signature will have already been dropped
at this point if all generic parameters were fully concrete, so use
the original generic signature to compute the reduced type of the
yield type.
Fixes https://github.com/apple/swift/issues/61040.
When computing the availability of a `SILFunction` for linkage the OS version specified in the `@_backDeploy` attribute should be preferred over the version in the `@available` attribute. This ensures that the corresponding symbol is weakly linked when deploying to older OSes than the back deploy "before" version.
Resolves rdar://99962885
Unify the mapped behavior with the unmapped
behavior and only ever walk into a pattern binding
decls, top-level code decls, and non-nested
functions. This avoids walking into e.g nested
types, leading to duplicate coverage.
We don't need to handle the unmapped behavior
separately, as top-level code decls are always
explicit, and non-nested functions are always
checked when we create the profiler.
rdar://99963912
This also enables address support for trivial types, but I need to do some
additional fixes until that is ready. But makes sense to get things in one step
at a time.
This is the only implicit getter case we care
about, the rest do not contain user-written code.
This means that we now otherwise only ever map
explicit decls, which we need to SILGen anyway. As
such I believe this should fix rdar://39332957.
We do still potentially map implicit expressions,
but should only do so for explicit property
initializers. There is one remaining bug where we
can map an implicit property wrapper backing
initalizer, which I'm tracking in rdar://99931619.
Use the new explicit ASTWalker actions to factor
out the skipping logic, ensuring to apply it in
post-visitation too, which fixes a PCMacro crash
(though I don't believe this is a configuration
that ever actually comes up). Also tighten up
invariants such that an `IfExpr` must appear
within an existing region.
