forked from llvm/llvm-project
-
Notifications
You must be signed in to change notification settings - Fork 342
Merge bastille into main #2048
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
shahmishal
merged 42 commits into
swiftlang:swift/main
from
JDevlieghere:merge-bastille-into-main
Oct 29, 2020
Merged
Merge bastille into main #2048
shahmishal
merged 42 commits into
swiftlang:swift/main
from
JDevlieghere:merge-bastille-into-main
Oct 29, 2020
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
for generating the mangled name of an Objective-C method. This has no intended functionality change. https://reviews.llvm.org/D88329
- Fix a memory leak accidentally introduced yesterday by using CodeGen's existing mangling context instead of creating a new context afresh. - Move GNU-runtime ObjC method mangling into the AST mangler; this will eventually be necessary to support direct methods there, but is also just the right architecture. - Make the Apple-runtime method mangling work properly when given an interface declaration, fixing a bug (which had solidified into a test) where mangling a category method from the interface could cause it to be mangled as if the category name was a class name. (Category names are namespaced within their class and have no global meaning.) - Fix a code cross-reference in dsymutil. Based on a patch by Ellis Hoag.
Cherrypick ObjC method mangling commits for Swift
This patch copies @vSK's fix to instcombine from D85555 over to mem2reg. The motivation and rationale are exactly the same: When mem2reg removes an alloca, it erases the dbg.{addr,declare} instructions which refer to the alloca. It would be better to instead remove all debug intrinsics which describe the contents of the dead alloca, namely all dbg.value(<dead alloca>, ..., DW_OP_deref)'s. As far as I can tell, prior to D80264 these `dbg.value+deref`s would have been silently dropped instead of being made `undef`, so we're just returning to previous behaviour with these patches. Testing: `llvm-lit llvm/test` and `ninja check-clang` gave no unexpected failures. Added 3 tests, each of which covers a dbg.value deletion path in mem2reg: mem2reg-promote-alloca-1.ll mem2reg-promote-alloca-2.ll mem2reg-promote-alloca-3.ll The first is based on the dexter test inlining.c from D89543. This patch also improves the debugging experience for loop.c from D89543, which suffers similarly after arg promotion instead of inlining. (cherry picked from commit fea067b)
For the reproducers in LLDB we want to switch to an "immediate mode" FileCollector that writes every file encountered straight to disk so we can generate the actual mapping out-of-process. This patch moves the interface into a separate base class. Differential revision: https://reviews.llvm.org/D89742 (cherry picked from commit f44fb13)
For performance reasons the reproducers don't copy the files captured by the file collector eagerly, but wait until the reproducer needs to be generated. This is a problematic when LLDB crashes and we have to do all this signal-unsafe work in the signal handler. This patch uses a similar trick to clang, which has the driver invoke a new cc1 instance to do all this work out-of-process. This patch moves the writing of the mapping file as well as copying over the reproducers into a separate process spawned when lldb crashes. Differential revision: https://reviews.llvm.org/D89600 (cherry picked from commit 73811d3)
[lldb] Move copying of files into reproducer out of process
[mem2reg] Remove dbg.values describing contents of dead allocas
temporaries created by conditional and assignment operators rdar://problem/64989559 Differential Revision: https://reviews.llvm.org/D83448 (cherry picked from commit 71e1a56)
[CodeGen] Emit destructor calls to destruct non-trivial C struct temporaries created by conditional and assignment operators
…nstants" This patch was reverted in 7c18266 due to some failures observed on PCC based machines. Failures were due to Endianness issue and long double representation issues. Patch is revised to address Endianness issue. Furthermore, support for emission of `DW_OP_implicit_value` for `long double` has been removed (since it was unclean at the moment). Planning to handle this in a clean way soon! For more context, please refer to following review link. Reviewed By: aprantl Differential Revision: https://reviews.llvm.org/D83560
This patch enables emitting DWARF `DW_OP_implicit_value` opcode when tuning debug information for LLDB (`-debugger-tune=lldb`). This will also propagate to Darwin platforms, since they use LLDB tuning as a default. rdar://67406059 Differential Revision: https://reviews.llvm.org/D90001 Signed-off-by: Med Ismail Bennani <[email protected]>
…ents Differential Revision: https://reviews.llvm.org/D86230
Follow-up to e787022 Differential Revision: https://reviews.llvm.org/D86230
[llvm/DebugInfo] Emit DW_OP_implicit_value when tuning for LLDB
Some of the predicates can't always be decided - for example when a type definition isn't available. At the same time it's necessary to let client code decide what to do about such cases - specifically we can't just use true or false values as there are callees with conflicting strategies how to handle this. This is a speculative fix for PR47276. Differential Revision: https://reviews.llvm.org/D88133
[Analyzer][WebKit] Use tri-state types for relevant predicates
Revert "[lldb] Move copying of files into reproducer out of process"
For the reproducers in LLDB we want to switch to an "immediate mode" FileCollector that writes every file encountered straight to disk so we can generate the actual mapping out-of-process. This patch moves the interface into a separate base class. Differential revision: https://reviews.llvm.org/D89742 (cherry picked from commit f44fb13)
…86380604101ce50a62a8d668b [FileCollector] Move interface into FileCollectorBase (NFC)
In %c (continuous sync) mode, avoid attempting to unlock an already-unlocked profile. The profile is only locked when profile merging is enabled. (cherry picked from commit a77a739)
[profile] Suppress spurious 'expected profile to require unlock' warning
On macOS, the read and pread syscalls return EINVAL when the number of bytes to read exceeds INT32_MAX: https://github.com/apple/darwin-xnu/blob/a449c6a3b8014d9406c2ddbdc81795da24aa7443/bsd/kern/sys_generic.c#L355 rdar://68751407 Differential revision: https://reviews.llvm.org/D90201 (cherry picked from commit c4ef311)
…1090ce33987d6fdf7fa337fc1 Fix calls to (p)read on macOS when size > INT32_MAX
This patch introduces a new ConstraintSystem class, that maintains a set of linear constraints and uses Fourier–Motzkin elimination to eliminate constraints to check if there are solutions for the system. It also adds a convert-constraint-log-to-z3.py script, which can parse the debug output of the constraint system and convert it to a python script that feeds the constraints into Z3 and checks if it produces the same result as the LLVM implementation. This is for verification purposes. Reviewed By: spatel Differential Revision: https://reviews.llvm.org/D84544
This reverts commit 3eb141e. This uses __builtin_mul_overflow which is not available everywhere.
…nts." This patch recommits "[ConstraintSystem] Add helpers to deal with linear constraints." (it reverts the revert commit 8da6ae4). The reason for the revert was using __builtin_multiply_overflow, which is not available for all compilers. The patch has been updated to use MulOverflow from MathExtras.h
gcc 7.4 warns about it.
This patch adds a isConditionImplied function that takes a constraint and returns true if the constraint is implied by the current constraints in the system. Reviewed By: spatel Differential Revision: https://reviews.llvm.org/D84545
This patch is a first draft of a new pass that adds a more flexible way to eliminate compares based on more complex constraints collected from dominating conditions. In particular, it aims at simplifying conditions of the forms below using a forward propagation approach, rather than instcomine-style ad-hoc backwards walking of def-use chains. if (x < y) if (y < z) if (x < z) <- simplify or if (x + 2 < y) if (x + 1 < y) <- simplify assuming no wraps The general approach is to collect conditions and blocks, sort them by dominance and then iterate over the sorted list. Conditions are turned into a linear inequality and add it to a system containing the linear inequalities that hold on entry to the block. For blocks, we check each compare against the system and see if it is implied by the constraints in the system. We also keep a stack of processed conditions and remove conditions from the stack and the constraint system once they go out-of-scope (= do not dominate the current block any longer). Currently there still are the least the following areas for improvements * Currently large unsigned constants cannot be added to the system (coefficients must be represented as integers) * The way constraints are managed currently is not very optimized. Reviewed By: spatel Differential Revision: https://reviews.llvm.org/D84547
…ied condition. NFC Delete an implied condition (E.NumIn <= CB.NumIn)
If -enable-constraint-elimination is specified, add it to the -O2/-O3 pipeline. (-O1 uses a separate function now.) Reviewed By: fhahn, aeubanks Differential Revision: https://reviews.llvm.org/D88365
This adds a new set of tests for upcoming constraint elimination changes.
-Oz normally does not allow loop header duplication so this loop wouldn't be vectorized. However the vectorization pragma should override this and allow for loop rotation. rdar://problem/49281061 Original patch by Adam Nemet. Reviewed By: Meinersbur Differential Revision: https://reviews.llvm.org/D59832
@swift-ci please test |
@swift-ci please test macos |
swiftlang/swift#34485 |
swift-ci
pushed a commit
that referenced
this pull request
Apr 12, 2021
Currently the ARM backend only accpets constant expressions as the immediate operand in load and store instructions. This allows the result of symbolic expressions to be used in memory instructions. For example, 0: .space 2048 strb r2, [r0, #(.-0b)] would be assembled into the following instructions. strb r2, [r0, #2048] This only adds support to ldr, ldrb, str, and strb in arm mode to address the build failure of Linux kernel for now, but should facilitate adding support to similar instructions in the future if the need arises. Link: ClangBuiltLinux/linux#1329 Reviewed By: peter.smith, nickdesaulniers Differential Revision: https://reviews.llvm.org/D98916
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.
No description provided.