[pull] swiftwasm-stable/20210726 from apple:stable/20210726 #1567
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
![pull[bot]](https://avatars.githubusercontent.com/in/12910?s=60&v=4){kind=small}
This patch uses a similar trick as in D113947 to only run the extra passes after vectorization on functions where loops have been vectorized. The reason for running the 'extra vector passes' is simplification/unswitching of the runtime checks created by LV, there should be no need to run them if nothing got vectorized To do that, a new dummy analysis ShouldRunExtraVectorPasses has been added. If loops have been vectorized for a function, LV will cache the analysis. At the moment it uses MadeCFGChanges as proxy for loop vectorized, which isn't perfect (it could be too aggressive, e.g. because no runtime checks have been added), but should be good enough for now. The extra passes are now managed by a new FunctionPassManager that runs its passes only if ShouldRunExtraVectorPasses has been cached. Without this patch, `-extra-vectorizer-passes` has the following compile-time impact: NewPM-O3: +4.86% NewPM-ReleaseThinLTO: +3.56% NewPM-ReleaseLTO-g: +7.17% http://llvm-compile-time-tracker.com/compare.php?from=ead3979a92fc33add4710c4510d6906260dcb4ad&to=c292da649e2c6e88a31e702fdc474727d09c72bc&stat=instructions With this patch, that gets reduced to NewPM-O3: +1.43% NewPM-ReleaseThinLTO: +1.00% NewPM-ReleaseLTO-g: +1.58% http://llvm-compile-time-tracker.com/compare.php?from=ead3979a92fc33add4710c4510d6906260dcb4ad&to=e67d86b57810011cf285eb9aa1944781be6096f0&stat=instructions It is probably still too high to enable by default, but much better. Reviewed By: aeubanks Differential Revision: https://reviews.llvm.org/D115052
[lldb] Bump macOS versions to 11 on the TestPlaygrounds test
…terFlags weak if it emits it When references to the symbol `swift_async_extendedFramePointerFlags` are emitted they have to be weak. References to the symbol `swift_async_extendedFramePointerFlags` get emitted only by frame lowering code. Therefore, the backend needs to track references to the symbol and mark them weak. Differential Revision: https://reviews.llvm.org/D115672 rdar://86432570
Improve error logging when ast context is in fatal error state.
The test shows how block placement can separate a call from the marker instruction and the ObjC call after CALL_RVMARKER expansion. (cherry-picked from 718a1c9)
This patch updates expandCALL_RVMARKER to wrap the call, marker and objc runtime call in an instruction bundle. This ensures later passes, like machine block placement, cannot break them up. On AArch64, the instruction sequence is already wrapped in a bundle. Keeping the whole instruction sequence together is highly desirable for performance and outweighs potential other benefits from breaking the sequence up. Reviewed By: ahatanak Differential Revision: https://reviews.llvm.org/D115230 (cherry-picked from ff3b085)
…FramePointerFlags_rdar_86432570_20210726 Teach the backend to make references to swift_async_extendedFramePointerFlags weak if it emits it
(cherry picked from commit 8b62429)
(cherry picked from commit 11c2af0)
The index added `SymbolSubKind::UsingEnum`. Add this to the indexstore as well. Resolves rdar://84229820
[stable/20210726][IndexStore] Add a UsingEnum subkind to match the index
The Swift expression parser uses the fixit mechanism to force SwiftASTContext to be reinitialized if it contains fatal errors. Playgrounds disable fixit application and thus defeated the mechanism. This became a problem after the late dylib notification was fixed in 1348ae3. This patch detects the situation where the fixit is identical to the original expression and makes one retry even if fixits are disabled. rdar://85431564
The test shows how block placement can separate a call from the marker instruction and the ObjC call after CALL_RVMARKER expansion. (cherry-picked from 718a1c9)
This patch updates expandCALL_RVMARKER to wrap the call, marker and objc runtime call in an instruction bundle. This ensures later passes, like machine block placement, cannot break them up. On AArch64, the instruction sequence is already wrapped in a bundle. Keeping the whole instruction sequence together is highly desirable for performance and outweighs potential other benefits from breaking the sequence up. Reviewed By: ahatanak Differential Revision: https://reviews.llvm.org/D115230 (cherry-picked from ff3b085)
This patch uses a similar trick as in D113947 to only run the extra passes after vectorization on functions where loops have been vectorized. The reason for running the 'extra vector passes' is simplification/unswitching of the runtime checks created by LV, there should be no need to run them if nothing got vectorized To do that, a new dummy analysis ShouldRunExtraVectorPasses has been added. If loops have been vectorized for a function, LV will cache the analysis. At the moment it uses MadeCFGChanges as proxy for loop vectorized, which isn't perfect (it could be too aggressive, e.g. because no runtime checks have been added), but should be good enough for now. The extra passes are now managed by a new FunctionPassManager that runs its passes only if ShouldRunExtraVectorPasses has been cached. Without this patch, `-extra-vectorizer-passes` has the following compile-time impact: NewPM-O3: +4.86% NewPM-ReleaseThinLTO: +3.56% NewPM-ReleaseLTO-g: +7.17% http://llvm-compile-time-tracker.com/compare.php?from=ead3979a92fc33add4710c4510d6906260dcb4ad&to=c292da649e2c6e88a31e702fdc474727d09c72bc&stat=instructions With this patch, that gets reduced to NewPM-O3: +1.43% NewPM-ReleaseThinLTO: +1.00% NewPM-ReleaseLTO-g: +1.58% http://llvm-compile-time-tracker.com/compare.php?from=ead3979a92fc33add4710c4510d6906260dcb4ad&to=e67d86b57810011cf285eb9aa1944781be6096f0&stat=instructions It is probably still too high to enable by default, but much better. Reviewed By: aeubanks Differential Revision: https://reviews.llvm.org/D115052
During the llvm round table it was generally agreed that the newer macho lld implementation is feature complete enough to replace the old implementation entirely. This will reduce confusion for new users who aren't aware of the history. Differential Revision: https://reviews.llvm.org/D114842 (cherry picked from commit 9e35525)
This now assumes that for the darwin driver any lld is the "new" macho lld implementation. Differential Revision: https://reviews.llvm.org/D114974 (cherry picked from commit ace03d0)
DwarfExpression::addUnsignedConstant(const APInt &Value) only supports wider-than-64-bit values when it is used to emit a top-level DWARF expression representing the location of a variable. Before this change, it was possible to call addUnsignedConstant on >64 bit values within a subexpression when substituting DW_OP_LLVM_arg values. This can trigger an assertion failure (e.g. PR52584, PR52333) when it happens in a fragment (DW_OP_LLVM_fragment) expression, as addUnsignedConstant on >64 bit values splits the constant into separate DW_OP_pieces, which modifies DwarfExpression::OffsetInBits. This change papers over the assertion errors by bailing on overly wide DW_OP_LLVM_arg values. A more comprehensive fix might be to be to split wide values into pointer-sized fragments. [0] https://github.com/llvm/llvm-project/blob/e71fa03/llvm/lib/CodeGen/AsmPrinter/DwarfCompileUnit.cpp#L799-L805 Patch by Ricky Zhou! Differential Revision: https://reviews.llvm.org/D115343 (cherry picked from commit c7c84b9)
… test file. Summary: Move the test case to existing test file. Remove test file as duplicated. The file was mistakenly added due to concerns of a hidden bug (see https://reviews.llvm.org/D104381). After it turned out, that the bug was already fixed with another revision (https://reviews.llvm.org/D85817) and corresponding test was added as well, we can remove this file. Differential Revision: https://reviews.llvm.org/D106152 (cherry picked from commit 497b1b9) (cherry picked from commit d3bae387bbc4406711c5c59072151e73df996691)
This change follows up on a FIXME submitted with D105974. This change simply let's the reference case fall through to return a concrete 'true' instead of a nonloc pointer of appropriate length set to NULL. Reviewed By: NoQ Differential Revision: https://reviews.llvm.org/D107720 (cherry picked from commit d39ebda) (cherry picked from commit 75f9657516e19e6c993c3fe410415459cf157adf)
Add some notes and track of bad return value. Reviewed By: steakhal Differential Revision: https://reviews.llvm.org/D107051 (cherry picked from commit 9f517fd) (cherry picked from commit a8e407f65d6904983bc63cf066befb7802f50528)
(cherry picked from commit 027c5a6) (cherry picked from commit 93117a9b047cb8878236914dc69380526b2a6a1f)
…ract NoStateChangeVisitor class Preceding discussion on cfe-dev: https://lists.llvm.org/pipermail/cfe-dev/2021-June/068450.html NoStoreFuncVisitor is a rather unique visitor. As VisitNode is invoked on most other visitors, they are looking for the point where something changed -- change on a value, some checker-specific GDM trait, a new constraint. NoStoreFuncVisitor, however, looks specifically for functions that *didn't* write to a MemRegion of interesting. Quoting from its comments: /// Put a diagnostic on return statement of all inlined functions /// for which the region of interest \p RegionOfInterest was passed into, /// but not written inside, and it has caused an undefined read or a null /// pointer dereference outside. It so happens that there are a number of other similar properties that are worth checking. For instance, if some memory leaks, it might be interesting why a function didn't take ownership of said memory: void sink(int *P) {} // no notes void f() { sink(new int(5)); // note: Memory is allocated // Well hold on, sink() was supposed to deal with // that, this must be a false positive... } // warning: Potential memory leak [cplusplus.NewDeleteLeaks] In here, the entity of interest isn't a MemRegion, but a symbol. The property that changed here isn't a change of value, but rather liveness and GDM traits managed by MalloChecker. This patch moves some of the logic of NoStoreFuncVisitor to a new abstract class, NoStateChangeFuncVisitor. This is mostly calculating and caching the stack frames in which the entity of interest wasn't changed. Descendants of this interface have to define 3 things: * What constitutes as a change to an entity (this is done by overriding wasModifiedBeforeCallExit) * What the diagnostic message should be (this is done by overriding maybeEmitNoteFor.*) * What constitutes as the entity of interest being passed into the function (this is also done by overriding maybeEmitNoteFor.*) Differential Revision: https://reviews.llvm.org/D105553 (cherry picked from commit c019142) (cherry picked from commit eb7fbf5d3986c19a7d6a3c964f9ac869b9cd65e6)
…that could have, but did not change ownership on leaked memory This is a rather common feedback we get from out leak checkers: bug reports are really short, and are contain barely any usable information on what the analyzer did to conclude that a leak actually happened. This happens because of our bug report minimizing effort. We construct bug reports by inspecting the ExplodedNodes that lead to the error from the bottom up (from the error node all the way to the root of the exploded graph), and mark entities that were the cause of a bug, or have interacted with it as interesting. In order to make the bug report a bit less verbose, whenever we find an entire function call (from CallEnter to CallExitEnd) that didn't talk about any interesting entity, we prune it (click here for more info on bug report generation). Even if the event to highlight is exactly this lack of interaction with interesting entities. D105553 generalized the visitor that creates notes for these cases. This patch adds a new kind of NoStateChangeVisitor that leaves notes in functions that took a piece of dynamically allocated memory that later leaked as parameter, and didn't change its ownership status. Differential Revision: https://reviews.llvm.org/D105553 (cherry picked from commit 2d3668c) (cherry picked from commit 2393aca2c6ab95ac0f0db9af453d4a8ead14826f)
This patch adds the flag `extra-checkers` to the sub-command `build` for passing a comma separated list of additional checkers to include. Differential Revision: https://reviews.llvm.org/D106739 (cherry picked from commit 198e677) (cherry picked from commit 6146abadae08954cb92aed452ced6a568a485012)
Summary: Change and replace some functions which IE does not support. This patch is made as a continuation of D92928 revision. Also improve hot keys behavior. Differential Revision: https://reviews.llvm.org/D107366 (cherry picked from commit 9dabacd) (cherry picked from commit 990b1e7c98fc944150ed1816040f4305eab9aab1)
(cherry picked from commit 32fa093)
Cache the result of TypeSystemSwiftTypeRef::LookupClangType(). …
(cherry picked from commit 2911abe)
This reverts commit 1ec03f3. rdar://90667314
[lldb] Unlock Swift scratch context before early return
Revert "[dsymutil] Emit an error when the Mach-O exceeds the 4GB limit."
rdar://90718091 (cherry picked from commit 352ab19)
rdar://90360204
[lldb] Disable PlatformRemoteMacOSX
Implement DLQ_GetPtrAuthMask using info from debugserver.
(cherry picked from commit fca7dc2)
Remove assertion
Skip TestPlatformSDK.py after 3c2ef81 because it relies on the now disabled remote-macosx platform.
Avoid "TERM environment variable not set" by either propagating the TERM environment variable or defaulting to vt100. All of our CI is already doing this explicitly through the --env dotest arg, but it's easy to forget when setting up a new job. I don't see any downside in making it the default. (cherry picked from commit 71f6077)
Fix the 5.6 CI
In some situations (swiftc bitcode) we end up running the objc-arc-contract pass twice, which is not supposed to occur. This was fine until relatively recently, where the clang.arc.attachedcall operand bundle support caused the second run to crash: when emitting the calls, the pass was assuming that the bundle always had an operand, which is not true in 5.6. That will be true in the future, but that's a massive change. For now, try to workaround the issue by ignoring the nullary bundles, and not emitting the call. The pass will get a little confused, but the semantics are preserved by the presence of the intrinsic call later on (emitted by the first run of the pass). However, one difference is that we're now going to emit a redundant inline-asm marker, since we're not able to eliminate the (standalone) intrinsic anymore, as we don't remember emitting it in the pass. That costs us an extra nop, which is okay. rdar://90366906
…undle [ObjCARC] Tolerate missing attachedcall op by ignoring the bundle.
AArch64: do not use xzr for ldxp -> stxp dataflow.
Disable these for now. They are known to be flakey and the failures reproduce neither on the llvm.org LLDB build bots nor locally.
[lldb][Test] Disable flakey tests on Swift branch
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
See Commits and Changes for more details.
Created by
pull[bot]
Can you help keep this open source service alive? 💖 Please sponsor : )