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
```
Merge conflict while removing `nocapture` from
`s21move_function_dbginfo20addressOnlyValueTestyyxAA1PRzlF`. Resolution
was to remove nocapture from the expected output in both cases:
```
// CHECK-LABEL: define swiftcc void @"$s21move_function_dbginfo20addressOnlyValueTestyyxAA1PRzlF"(ptr noalias[-nocapture-] %0, ptr %T, ptr %T.P)
```
Conflict cause: 4858cb6225
This is the same as the original change to this file. The conflict seems
to be due to the next line changing, when moving from llvm.dbg.addr to
llvm.dbg.value.
Conflicts:
test/DebugInfo/move_function_dbginfo.swift
The use of 'nocapture' for parameters and return values is incorrect for C++ types, as they can actually capture a pointer into its own value (e.g. std::string in libstdc++)
rdar://115062687
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
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.
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.
Before, we were silently hoisting the llvm.dbg.addr associated with this value.
Now LLVM understands not to do that, so we appropriately get the two variable
locations.
Some notes:
1. I only updated the dwarf dump checks for the cases where the test case I was
adding already had checks. The rest I am going to add the dwarf checks all at
once in a subsequent commit.
2. In the dwarf checks that I wrote, there are a few issues that show up due to
some LLVM fixes that I need to finish upstreaming. Once I upstream them, I will
be able to enable the specific patterns I have disabled. This ensures I atleast
will be able to tell if I am changing the current codegen.
3. This is dependent on the previous commit since one of the test cases hit the
bug fixed by the previous commit.
This reverts commit a182a7085d.
I also fixed the tests as well.
NOTE: In the generic case of debug_value_addr, the self parameter with asserts
seems to be a var and without asserts a let. This is apparent at the AST level
before we even get to anything that I have changed. This seems to suggest that
there is some sort of uninitialized memory or something like that. Regardless
that is more of an AST level thing, so I just put in a regex that match both
patterns and send rdar://89237318 over to Robert Widmann!
This has a few nice benefits:
1. The splitting happens after LLVM optimizations have run. This ensures that
LLVM will not join these blocks no matter what! The author of this commit has
found that in certain cases LLVM does this even at -Onone. By running this late,
we get the benefit we are looking for: working around the bad SelectionDAG
behavior.
2. This block splitting is just a workaround for the above mentioned unfortunate
SelectionDAG behavior. By doing this when we remove the workaround, we will not
have to update SIL level tests... instead we will just remove a small LLVM pass.
Some additional notes:
1. Only moved values will ever have llvm.dbg.addr emitted today, so we do not
have to worry about this impacting the rest of the language.
2. The pass's behavior is tested at the IR level by move_function_dbginfo.swift.
Otherwise if the move is in a different scope, the backend will think that we
have two different variables and emit the corresponding dwarf.
After I have this commit in and my alloc stack hoising commit (via a different
PR), I am going to be able to commit a full end <-> end test in lldb that values
are printed out appropriately as their lifetimes begin/end.
The reason why I am doing this is that right now SelectionDAG seems to sink
certain llvm.dbg.addr to the end of block. By breaking the block, we ensure that
we initialize the debug value of values early enough. NOTE: We are relying on
code at -Onone not eliminating control flow which it does not today.
A few additional notes:
1. I also fixed a small issue where I was not setting the proper debug scope for
reinit debug_values. This came up when I was writing test cases for this commit.
So I just fixed it at the same time.
2. Since I am splitting blocks and I don't want to invalidate dominators/etc at
this point in the pipeline, I took advantage of the APIs ability to update
dominators/loopinfo at the same time.
3. I also expanded the tests in tree further by adding debug info tests for the
reinit copyable/addressonly cases in the multi-block case.
The backend in order to emit correct dwarf requires the debug info part of the
dbg.addr or dbg.value to be exactly the same, including the line info. We obey
this in the examples in tree today and these test additions validate that they
continue to work correctly.
This fixes the issues I was in my earlier PR about seeing with vars not getting
appropriate debug info when moved. Now we get the right debug info and in the
dwarf can see the two live ranges of our moved value as we hoped for.
NOTE: I disabled alloc stack hoisting on move_function_debuginfo.swift since it
can result in us eliminating debug info at -Onone when we merge alloc_stack. I
am preparing a separate patch that fixes that issue but hit a lldb problem. This
unblocks this PR from that change since they are not /actually/ related.
LLVM wants the debug_value undef to be /exactly/ the same as the original
debug_value including the loc. If we don't match, LLVM won't invalidate the
value.
Also now that things actually work (at least for copyable lets), lets add some
basic tests that debug info works as expected. NOTE: With this patch it seems
that address only move is still broken. I am looking into it and will fix it in
a forthcoming PR.
