Skip to content

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
merged 42 commits into from
Oct 29, 2020
Merged

Merge bastille into main #2048

merged 42 commits into from
Oct 29, 2020

Conversation

JDevlieghere
Copy link

No description provided.

ellishg and others added 30 commits October 22, 2020 15:43
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]>
[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
fhahn and others added 12 commits October 27, 2020 12:12
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
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
@JDevlieghere JDevlieghere changed the base branch from apple/stable/20200714 to swift/main October 27, 2020 15:46
@JDevlieghere
Copy link
Author

@swift-ci please test

@JDevlieghere
Copy link
Author

@swift-ci please test macos

@benlangmuir
Copy link

swiftlang/swift#34485
@swift-ci please test macOS

@shahmishal shahmishal merged commit 1c21b96 into swiftlang:swift/main Oct 29, 2020
@JDevlieghere JDevlieghere deleted the merge-bastille-into-main branch October 29, 2020 01:22
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
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.