Introduce a new pass MandatoryTempRValueElimination, which works as the original TempRValueElimination, except that it does not remove any alloc_stack instruction which are associated with source variables.
Running this pass at Onone helps to reduce copies of large structs, e.g. InlineArrays or structs containing InlineArrays.
Copying large structs can be a performance problem, even at Onone.
rdar://151629149
Use the `%target-swift-5.1-abi-triple` substitution to compile the tests for
deployment to the minimum OS versions required for use of _Concurrency APIs,
instead of disabling availability checking.
The support for DIExpression constant folding has been added to the
Corosplit pass, this patch fixes up the swift tests that need to account
for the changes in the DIExpressions.
With https://github.com/apple/llvm-project/pull/7787 merged, we can now finally
renable these tests, as the x86 swift async handling should be properly
preserved by the x86 instruction selector.
These tests contained some incorrect checks from a time where it was expecting
an entry value even in the entry funclet of coroutines. For example, it had
this:
```
CHECK-NEXT: [[ASYNC_REG:DW_OP_.*], DW_OP_plus_uconst 0x10, DW_OP_plus_uconst 0x8,
DW_OP_deref
```
Which tries to find some "async reg", but really matches anything. It worked by
accident on arm, but not on x86. The correct check is simply:
```
CHECK-NOT: OP_entry_value
```
The following tests required conflict resolutions, since upstream LLVM did a lot of
work to remove dbg.addr, and this work is not available to swift's main. At the
same time, swift's main changed these tests to enable opaque pointers.
```
both modified: test/DebugInfo/async-let-await.swift
both modified: test/DebugInfo/move_function_dbginfo.swift
both modified: test/DebugInfo/move_function_dbginfo_async.swift
```
The conflicts are fairly easy to fix: we keep the "structure" of the CHECK
lines present in `next`, but replace all pointers with `ptr`.
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.
the main things still left behind the experimental flag(s) are
- move-only classes (guarded by MoveOnlyClasses feature)
- noimplicitcopy
- the _borrow operator
Originally move when it was in the stdlib as _move was behind a keyword but we
moved it in front to allow for some testing. Now that we are going with a
keyword (which we can't leave in/deprecate) move it behind the move only
experimental flag until this gets through evolution.
I also updated the move function tests to show that this is working. As a nice
bonus, I was able to enable all of the tests also in a non-optimized stdlib.
The overall flow of the pass is:
1. We walk over the blocks summarizing the debug info instruction the blocks gen
as well as whether or not the block had an async funclet edge with in it.
2. We then perform a simple forward iterative optimistic dataflow using
intersection at merge points. At points where we find after merging that we have
a conflict and thus need to stop propagation, we insert a debug_value undef.
3. We then walk the CFG again visiting only blocks that we know had async
funclet edges. We then walk each said block from top to bottom starting with the
propagating gen information and updating as we go, dumping the current set of
debug_info we are tracking after each coroutine funclet boundary.
rdar://85020571
Otherwise there is a potential that various versions of the compiler may use a
slightly different register causing the test to fail. We are not attempting to
test this so it just makes sense to make this a more general pattern.
rdar://91467528
The pattern started to fail here since the variable "m" is not a variable that
we moved so as a result we use heuristics to determine if it should become an
entry value.
Noting that we only pattern match "m" to ensure that we can easily check the
variable "k" afterwards (the thing that was actually moved), I just loosened the
pattern so that we validate that we found "m" but do not check "m"'s
location. This guarantees that on all platforms this will pattern match
appropriately.
rdar://91467528
I fixed the issues exposed with alloc-stack-hoisting for llvm.dbg.addr some time
ago but didn't update this test.
The test changes are b/c I did not fix this for llvm.dbg.declare resulting in us
losing the variable "m" in certain situations. "k" the thing we care about is
actually fine though.
I changed code upstream so that we are always guaranteed to have an entry value
for async arguments on r14. The main effect of this is that it eliminates a bunch of
cases where r14 would be spilled simplifying weird patterns in the test cases.
I also added additional commentary to the Dwarf part of the test cases
explaining what the patterns are checking and why.
The reason that I am doing this is that otherwise in funclets we may show an
invalidated value being available if we have an llvm.dbg.addr for a reinit value
later in the funclet. This ensures that we have the undef at the beginning of
the funclet so before that llvm.dbg.addr we will properly show no value.
The specific problem was that we assume that SILGen will only emit a single
debug_value for a value. This condition breaks once we start processing since we
are inserting extra debug_value when reiniting. The end result is that we do not
insert the undef, addr. To fix this I just hoisted out this computation upon the
address before we do anything.
This uses the previous simple dominance dbg info propagation implementation in
the previous commit.
I fix in the next commit the debug info for the last move/reinit in the var
test.
