forked from llvm/llvm-project
-
Notifications
You must be signed in to change notification settings - Fork 0
[pull] swiftwasm from swift/main #1094
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Merged
Merged
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
…tion attribute id changes When introducing support for @llvm.experimental.noalias.scope.decl, this tests started failing because it checks (for no good reason) for a function attribute id of '#8' which now becomes '#9' Reviewed By: pratlucas Differential Revision: https://reviews.llvm.org/D94233
fix typo under include and lib directories Reviewed By: antiagainst Differential Revision: https://reviews.llvm.org/D94220
Remove continuation line in code snippet to prevent GCC warning about multiline comments (-Wcomment) when building a project using libclang with GCC. Reviewed By: rjmccall Differential Revision: https://reviews.llvm.org/D92409
As shown by bug 48540, GCC vector types would cause a crash when the declaration hada ParenType. This was because the walking of the declaration would try to expand the 'inner' type, but there was no ability to get it from the vector type. This patch adds that element type access to the vector type loc objects. Differential Revision: https://reviews.llvm.org/D93483
rdar://72434219
…m-LLDBMemoryReader-readString-rebranch [lldb] Optimize target read from LLDBMemoryReader::readString
… up. (cherry picked from commit 9bbf396)
(cherry picked from commit 0627fa3)
(cherry picked from commit c9ba5e2)
LLDBTypeInfoProvider only requires a TypeSystemSwift. (cherry picked from commit e27eeeb)
This does the exact same amount of locking as the previous version, it's just slightly more efficient to use ForEach(). (cherry picked from commit 88c0bf6)
and SwiftLanguageRuntimeImpl::ModulesDidLoad() SetupABIBit() iterates of the Target's images and thus needs to acquire that ModuleList's lock. We need to acquire this before locking m_add_module_mutex, since ModulesDidLoad can also be called from a place where that lock is already held: + lldb_private::DynamicLoaderDarwin::AddModulesUsingImageInfos() + lldb_private::ModuleList::AppendIfNeeded() + lldb_private::Target::NotifyModuleAdded() + lldb_private::Target::ModulesDidLoad() rdar://72858062 (cherry picked from commit 6a79a97)
There is only one lock per target (not per lldb::Module) so that comment was incorrect. rdar://67587895 (cherry picked from commit 6f69f18)
(cherry picked from commit e98d603)
…s-only-when-verbose-rebranch [lldb] Log MemoryReader messages only when verbose
- Remove unused plists that were referenced (but unused) by Xcode. - Move all debugserver plists unders tools/debugserver/resources. - Add the ability to distinguish between com.apple.security.cs.debugger and com.apple.private.cs.debugger. rdar://66082043 Differential revision: https://reviews.llvm.org/D94320 (cherry picked from commit 2723551)
Remove an incorrect FIXME.
72858062 rebranch
…56faff3b704f3957f941b7
This type is used as an aggregate, i.e. it has no member functions. Starting with C++20 types with deleted default constructors are not aggregate types anymore which means that aggregate initialization will not work for this class anymore. This leads to a compile error in clang::AnalyzerOptions::getDiagOpts() for example. Also set the boolean flags to false by default to avoid undefined behavior. Previously this was prevented by deleting the default constructor, now we explicitly initialize them. Differential Revision: https://reviews.llvm.org/D92221 (cherry picked from commit e16959c)
NamedDecl::getName() was being called on a constructor. (cherry picked from commit c435567)
Differential Revision: https://reviews.llvm.org/D95249 (cherry picked from commit 91b61ab)
Replace cast_or_null<> with cast<> as we immediately dereference the pointer afterward so we're not expecting a null pointer. (cherry picked from commit 879c12d)
…cs". Currently only used by MoveChecker but ideally all checkers should have reusable categories. (cherry picked from commit 3e206a5)
Drop redundant "found", specify what exactly is wrong with side effects in assert conditions. Differential Revision: https://reviews.llvm.org/D95515 (cherry picked from commit ec81289)
NSAssert and NSCAssert are Objective-C Foundation's standard assert macros. Differential Revision: https://reviews.llvm.org/D95519 (cherry picked from commit b92a39a)
Static analyzer cherrypicks 17
This is a drive-by fix of something that's obviously wrong, but I don't have a testcase for it yet.
rdar://73760364
[lldb/test] Xfail TestSwiftBenchmarkOnone.1.test
This pre-commits tests for D95468.
This patch fixes updating MemorySSA if the header contains memory defs that do not clobber a duplicated instruction. We need to find the first defining access outside the loop body and use that as defining access of the duplicated instruction. This fixes a crash caused by bee4868.
If we determine that the invariant path through the loop has no effects, we can directly branch to the exit block, instead to unswitching first. Besides avoiding some extra work (unswitching first, then deleting the loop again) this allows to be more aggressive than regular unswitching with respect to cost-modeling. This approach should always be be desirable. This is similar in spirit to D93734, just that it uses the previously added checks for loop-unswitching. I tried to add the required no-op checks from scratch, as we only check a subset of the loop. There is potential to unify the checks with LoopDeletion, at the cost of adding a predicate whether a block should be considered. Reviewed By: jdoerfert Differential Revision: https://reviews.llvm.org/D95468
Attempt to fix some compiler warnings on some bots after b8c81fa.
Otherwise getZExtValue() asserts.
Swift's new concurrency features are going to require guaranteed tail calls so that they don't consume excessive amounts of stack space. This would normally mean "tailcc", but there are also Swift-specific ABI desires that don't naturally go along with "tailcc" so this adds another calling convention that's the combination of "swiftcc" and "tailcc". Support is added for AArch64 and X86 for now.
Otherwise getZExtValue() asserts.
IR/AArch64/X86: add "swifttailcc" calling convention.
GlobalISel: check type size before getZExtValue()ing it.
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 : )