Put AvailabilityRange into its own header with very few dependencies so that it
can be included freely in other headers that need to use it as a complete type.
NFC.
Although I don't plan to bring over new assertions wholesale
into the current qualification branch, it's entirely possible
that various minor changes in main will use the new assertions;
having this basic support in the release branch will simplify that.
(This is why I'm adding the includes as a separate pass from
rewriting the individual assertions)
AllocStackHoisting was losing debug info, including at -Onone.
When two alloc_stacks of the same type are merged, one of them
would lose their debug variable. It is now salvaged, with an added
debug_value.
This case was previously only handled for noncopyable types, it is
now done in all cases.
Renamed "getUsesMoveableValueDebugInfo" to "usesMoveableValueDebugInfo".
Clarifies the predicate from "does the receiver have the
usesMoveableValueDebugInfo field set?" to "does the receiver use moveable
value debug info?".
Use consecutive instruction numbers to check for overlapping instead of iterating over the instruction list.
This fixes a compile time problem which shows up if there are many stack locations in a large basic block.
rdar://113207176
This is phase-1 of switching from llvm::Optional to std::optional in the
next rebranch. llvm::Optional was removed from upstream LLVM, so we need
to migrate off rather soon. On Darwin, std::optional, and llvm::Optional
have the same layout, so we don't need to be as concerned about ABI
beyond the name mangling. `llvm::Optional` is only returned from one
function in
```
getStandardTypeSubst(StringRef TypeName,
bool allowConcurrencyManglings);
```
It's the return value, so it should not impact the mangling of the
function, and the layout is the same as `std::optional`, so it should be
mostly okay. This function doesn't appear to have users, and the ABI was
already broken 2 years ago for concurrency and no one seemed to notice
so this should be "okay".
I'm doing the migration incrementally so that folks working on main can
cherry-pick back to the release/5.9 branch. Once 5.9 is done and locked
away, then we can go through and finish the replacement. Since `None`
and `Optional` show up in contexts where they are not `llvm::None` and
`llvm::Optional`, I'm preparing the work now by going through and
removing the namespace unwrapping and making the `llvm` namespace
explicit. This should make it fairly mechanical to go through and
replace llvm::Optional with std::optional, and llvm::None with
std::nullopt. It's also a change that can be brought onto the
release/5.9 with minimal impact. This should be an NFC change.
This patch replaces the stateful generation of SILScope information in
SILGenFunction with data derived from the ASTScope hierarchy, which should be
100% in sync with the scopes needed for local variables. The goal is to
eliminate the surprising effects that the stack of cleanup operations can have
on the current state of SILBuilder leading to a fully deterministic (in the
sense of: predictible by a human) association of SILDebugScopes with
SILInstructions. The patch also eliminates the need to many workarounds. There
are still some accomodations for several Sema transformation passes such as
ResultBuilders, which don't correctly update the source locations when moving
around nodes. If these were implemented as macros, this problem would disappear.
This necessary rewrite of the macro scope handling included in this patch also
adds proper support nested macro expansions.
This fixes
rdar://88274783
and either fixes or at least partially addresses the following:
rdar://89252827
rdar://105186946
rdar://105757810
rdar://105997826
rdar://105102288
This is in preparation for wiring up debug info support for noncopyable
values. Originally this flag name made sense since it was set when we performed
consume operator checking. Now I am going to use it for noncopyable types as
well. I think the new name uses_moveable_value_debuginfo actually describes what
the flag is supposed to do, tell IRGen that the value may be moved since it
needs to use moveable value debug info emission.
This is just a quick fix to stop us from dropping live values such as m in the
following example:
```
public func addressOnlyVarTest<T : P>(_ x: T) {
var k = x
k.doSomething()
let m = _move(k)
m.doSomething()
k = x
k.doSomething()
}
```
Before this change, we would just drop m and one wouldn't even see it in the
debugger.
I am only doing this currently for cases where when we merge at least one
alloc_stack was moved. The reason why is that to implement this correctly, I
need to use llvm.dbg.addr and changing the debug info from using
llvm.dbg.declare -> llvm.dbg.addr requires statistics and needs to be done a
little later in the swift development process. If one of these alloc_stack had
the [moved] marker attached to it, we know the user /did/ use move so they have
in a sense opted into having a move function effect its program so we are only
changing how new code appears in the debugger.
AllocStackHoisting creates new dealloc_stack instructions. The old
dealloc_stack instructions' locations' kinds are ::CleanupKind The new
instructions' locations need to be of that same kind too in order not to
trigger the sil verifier failure
Basic block contains a non-contiguous lexical scope at -Onone
when building at Onone.
To make it possible to change the implementation of
_stdlib_isOSVersionAtLeast(), remove the @inlinable attribute from it.
Since it is currently inlinable and calls the helper function
_swift_stdlib_operatingSystemVersion(), we’ll have to keep the
helper around as ABI.
This change causes a minor pessimization where the LLVM optimizer can no
longer reason that, for example, a successful check for 10.12 availability
means that a later check for 10.11 will always succeed. I don't expect this
pessimization to be a problem, but if needed we could write a custom SIL
optimizer pass to claw back the performance.
<rdar://problem/59447474>
First, remove the AvailabilityContext parameter; it was confusing because
we actually always want to use the deployment target here.
Then, split this method up into three methods:
- isAlwaysWeakImported(): simply checks for a @_weakLinked attribute, either
on the declaration itself or one of its parent contexts.
- getAvailabilityForLinkage(): returns the OS version availability when
this declaration was introduced, or if the declaration does not have
explicit availability, check it's storage (if its an accessor), or its
parent contexts.
- isWeakImported(ModuleDecl *fromModule): combines these two checks to
determine if the declaration should be weak linked when referenced from
the given module, or if it might be weak referenced from some module
(if the module parameter is null).
With the advent of dynamic_function_ref the actual callee of such a ref
my vary. Optimizations should not assume to know the content of a
function referenced by dynamic_function_ref. Introduce
getReferencedFunctionOrNull which will return null for such function
refs. And getInitialReferencedFunction to return the referenced
function.
Use as appropriate.
rdar://50959798
This disables inlinability of _stdlib_isOSVersionAtLeast. I don't see
value in making it inlinable as long as _swift_stdlib_operatingSystemVersion is
opaque.
rdar://41849700
And unbreak the LLDB testsuite.
This patch fixes three problems with the original implementation:
- Use SILBuilderWithScope instead of SILBuilder to avoid holes in the
lexical scopes.
- Use an artificial location for stores to the alloca to avoid the debugger
stopping before the variable is initialized.
- Recognize debug_value_addr instructions referring to an alloc_stack
instruction to avoid introducing an extra indirection in the debug info.
rdar://problem/31975108
This is a very easily misused API since it allows for users to leak instructions
if they are not careful. This commit removes this API and replaces the small
number of uses of this API with higher level APIs that accomplish the same task
without using removeFromParent(). There were no API users that specifically
required removeFromParent.
An example of one way we were using removeFromParent is to move a SILInstruction
to the front of a block. That does not require exposing an API like
removeFromParent()... we can just create a higher level API like the one added
in this commit: SILInstruction::moveFront(SILBasicBlock *).
rdar://31276565
At some point, pass definitions were heavily macro-ized. Pass
descriptive names were added in two places. This is not only redundant
but a source of confusion. You could waste a lot of time grepping for
the wrong string. I removed all the getName() overrides which, at
around 90 passes, was a fairly significant amount of code bloat.
Any pass that we want to be able to invoke by name from a tool
(sil-opt) or pipeline plan *should* have unique type name, enum value,
commend-line string, and name string. I removed a comment about the
various inliner passes that contradicted that.
Side note: We should be consistent with the policy that a pass is
identified by its type. We have a couple passes, LICM and CSE, which
currently violate that convention.
We hit an assert in AllocStackHoisting that is only triggered in a release lto
build.
Clang forwards the read of parent basic block of 'AssignedLoc' in the next
statement:
auto *EntryBB = AssignedLoc->getFunction()->getEntryBlock(); // read AssignedLoc->ParentBB
AssignedLoc->removeFromParent(); // writes AssignedLoc->ParentBB
To this read:
EntryBB->push_front(AssignedLoc); // read AssignedLoc->ParentBB and assert if non-null, *should reload*
As a temporary workaround outline code to prevent the miscompile.
rdar://29982182
Hoist alloc_stack instructions of 'generic' or resilient type to the entry
block. At the same time also perform a very simple stack coloring analysis.
This does not use a true liveness-analysis yet but rather employs some simple
conservative checks to see whether the live ranges of two alloc_stacks might
interfere.
AllocStackHoisting is an IRGen SIL pass. This allows for using IRGen's type
lowering information. Furthermore, hoisting and merging the alloc_stack
instructions this late does not interfere with SIL optimizations because the
resulting SIL never gets serialized.
