llvm-svn: 354847

For outgoing varargs arguments, it's necessary to check the OrigAlign field
of the corresponding OutputArg entry to determine argument alignment, rather
than just computing an alignment from the argument value type. This is
because types like fp128 are split into multiple argument values, with
narrower types that don't reflect the ABI alignment of the full fp128.

This fixes the printf("printfL: %4.*Lf\n", 2, lval); testcase.

Differential Revision: https://reviews.llvm.org/D58656

llvm-svn: 354846

As requested during review of D57601 <https://reviews.llvm.org/D57601> https://reviews.llvm.org/D57601, be equally conservative for atomic MMOs as for volatile MMOs in all in tree backends. At the moment, all atomic MMOs are also volatile, but I'm about to change that.

Differential Revision: https://reviews.llvm.org/D58490

Note: D58498 landed in several pieces as individual backends were approved.  This is the last chunk.
llvm-svn: 354845

Summary: We shouldn't delete elements while iterating a ranged for loop.

Reviewers: dschuff

Subscribers: sbc100, jgravelle-google, sunfish, llvm-commits

Tags: #llvm

Differential Revision: https://reviews.llvm.org/D58519

llvm-svn: 354844

This goes with https://reviews.llvm.org/D44406

llvm-svn: 354843

Summary:
- Indent check lines to easily figure out try-catch-end structure
- Add the original C++ code the tests were genereated from
- Add a few more lines to make the structure more readable
- Rename a couple function / structures
- Add label and branch annotations to cfg-stackify-eh.ll
- Temporarily delete check lines for `test1` in `cfg-stackify-eh.ll`
  because it will be updated in a later CL soon and there's no point of
  making it look better here

Reviewers: dschuff

Subscribers: sunfish, sbc100, jgravelle-google, llvm-commits

Tags: #llvm

Differential Revision: https://reviews.llvm.org/D58562

llvm-svn: 354842

Reviewers: zturner, rnk, llvm-commits, aleksandr.urakov

Reviewed By: zturner, rnk

Subscribers: jdoerfert, majnemer, asmith

Tags: #llvm

Differential Revision: https://reviews.llvm.org/D44406

llvm-svn: 354841

Summary:
The llvm-cov tool needs to be able to find coverage names in the
executable, so the .lprfn and .lcovmap sections cannot be merged into
.rdata.

Also, the linker merges .lprfn$M into .lprfn, so llvm-cov needs to
handle that when looking up sections. It has to support running on both
relocatable object files and linked PE files.

Lastly, when loading .lprfn from a PE file, llvm-cov needs to skip the
leading zero byte added by the profile runtime.

Reviewers: vsk

Subscribers: hiraditya, #sanitizers, llvm-commits

Tags: #sanitizers, #llvm

Differential Revision: https://reviews.llvm.org/D58661

llvm-svn: 354840

Test does not pass on Windows

llvm-svn: 354839

Patch by Zahira Ammarguellat!

Differential Revision: https://reviews.llvm.org/D41950

llvm-svn: 354838

Summary:
Use a custom calling convention handler for interrupts instead of fixing
up the locations in LowerMemArgument. This way, the offsets are correct
when constructed and we don't need to account for them in as many
places.

Depends on D56883

Replaces D56275

Reviewers: craig.topper, phil-opp

Subscribers: hiraditya, llvm-commits

Differential Revision: https://reviews.llvm.org/D56944

llvm-svn: 354837

This is a second attempt at r342652 using a TLS callback instead of an
interceptor.

In long-running builds we've seen some ASan complaints during thread creation
that we suspect are due to leftover poisoning from previous threads whose
stacks occupied that memory. This patch adds a callback that unpoisons the
stack memory when a thread exits.

Differential Revision: https://reviews.llvm.org/D58641

llvm-svn: 354836

Tests were accidentally enabled r354829.

llvm-svn: 354834

Specifically, compute and Print Type and Section columns.

Differential Revision: https://reviews.llvm.org/D58263

llvm-svn: 354833

Summary:
This allows ASTs to be merged when they contain ChooseExpr (the GNU
__builtin_choose_expr construction). This is needed, for example, for
cross-CTU analysis of C code that makes use of __builtin_choose_expr.

The node is already supported in the AST, but it didn't have a matcher
in ASTMatchers. So, this change adds the matcher and adds support to
ASTImporter.

Reviewers: shafik, a_sidorin, martong, aaron.ballman

Subscribers: aaron.ballman, rnkovacs, jdoerfert, cfe-commits

Tags: #clang

Differential Revision: https://reviews.llvm.org/D58292

llvm-svn: 354832

I somehow had misaligned some of the tests when I originally wrote this. Re-order them properly.

llvm-svn: 354831

Test was used without -mcpu, although tested instructions
not available on all ASICs.

llvm-svn: 354830

Summary:
ASan and Scudo tests are adding "-android" to test arch.
There are no tests that depend on it as far as I can see.
If necessary, do this instead:
  REQUIRES: aarch64-target-arch && android

Reviewers: pcc, vitalybuka

Subscribers: srhines, kubamracek, mgorny, javed.absar, kristof.beyls, cryptoad, #sanitizers, llvm-commits

Tags: #sanitizers, #llvm

Differential Revision: https://reviews.llvm.org/D58532

llvm-svn: 354829

Try to use concat_vectors. Also remove unnecessary assert on
pointers. Fixes asserting for <4 x s16> operations and 64-bit pointers
for AMDGPU.

llvm-svn: 354828

This reverts commit e50038e4.

llvm-svn: 354827

ObjCMessageExpr::getInstanceReceiver returns nullptr if the receiver
is 'super'. Make this check more strict, since we don't care about
messages to super here.

rdar://48247290

llvm-svn: 354826

llvm-svn: 354825

This is helpful to properly detect them, and fixing issues like
https://github.com/rust-lang/rust-bindgen/issues/1518.

Differential Revision: https://reviews.llvm.org/D58570

llvm-svn: 354824

The value for CXCursor_ConvergentAttr is not 420. I'm not really sure how easy
it is to test this, and I'm not familiar with the python bindings, just noticed
the error while looking at D57946 to write D58570.

Differential Revision: https://reviews.llvm.org/D58571

llvm-svn: 354823

Shame on me, did not run all the tests, bots are angry.

This reverts commit r354819.

llvm-svn: 354822

We have all the necessary legalization, expansion and unrolling support required for the *.overflow intrinsics with vector types, so update the docs to make that clear.

Note: vectorization is not in place yet (the non-homogenous return types aren't well supported) so we still must explicitly use the vectors intrinsics and not reply on slp/loop.

Differential Revision: https://reviews.llvm.org/D58618

llvm-svn: 354821

Summary:
In D58580 i have noted that `llvm::to_string()` is a memory hog.
It uses `raw_string_ostream`, and since it was buffered,
every `raw_string_ostream` had a cost of `BUFSIZ` bytes
(which is `8192` at least here). So every `llvm::to_string()`
call, even to just print an `int`, costed `8192` bytes.

In D58580, getting rid of that buffering //had// significant
performance and memory consumption improvements for `llvm-xray convert`.

Similarly, in D58580 @rnk pointed out that the `raw_svector_ostream`
is already unbuffered, and `write_unsigned_impl` and friends
do internal buffering. So it should be ok performance-wise to just
make the `raw_string_ostream` itself unbuffered.

Here, i don't have any perf measurements.
Another letdown is that i'm leaving a loose-end - not deleting the
`flush()` method. I  don't expect that cleanup to be anything more
than just fixing every new compiler error, but i'm presently unable
to do that. Will look into that later.

Reviewers: rnk, zturner

Reviewed By: rnk

Subscribers: kristina, jdoerfert, llvm-commits, rnk

Tags: #llvm

Differential Revision: https://reviews.llvm.org/D58643

llvm-svn: 354819

llvm-svn: 354818

This patch implements the parsing and sema support for the OpenMP
'from'-clause with potential user-defined mappers attached.
User-defined mappers are a new feature in OpenMP 5.0. A 'from'-clause
can have an explicit or implicit associated mapper, which instructs the
compiler to generate and use customized mapping functions. An example is
shown below:

    struct S { int len; int *d; };
    #pragma omp declare mapper(id: struct S s) map(s, s.d[0:s.len])
    struct S ss;
    #pragma omp target update from(mapper(id): ss) // use the mapper with name 'id' to map ss from device

Contributed-by: Lingda Li <lildmh@gmail.com>

Differential Revision: https://reviews.llvm.org/D58638

llvm-svn: 354817

AMDGPU wants to use this in some contexts where
the spilling is either impossible, or a worse alternative
to doing something else.

llvm-svn: 354816

EarlyCSE with MemorySSA was able to use this to merge multiple calls
with no intervening store.

llvm-svn: 354814

If no phi existed in the original MIR and these introduced one, the
verifier would fail.

llvm-svn: 354813

This reverts commit r354795, I suspect it is causing test failures
on MSan sanitizer bots.

llvm-svn: 354812

[X86] Improve detection of unneeded shift amount masking to also handle the case that the LHS has known zeroes in it

If the LHS has known zeros, the RHS immediate will have had bits removed. So call computeKnownBits to get the known zeroes so we can handle this case.

Differential Revision: https://reviews.llvm.org/D58475

llvm-svn: 354811

The warning was introduced at r354793.

llvm-svn: 354810

These really read and write the result register, so these need a tied
input.

llvm-svn: 354809

Fixes https://bugs.llvm.org/show_bug.cgi?id=40325 by zero extending
(and x, 1) the condition before branching on it.

To avoid regressing trivial cases, I'm combining emission of cmp+br
sequences for the single-use + same block case (similar to what we
do in x86). icmpbr1.ll still regresses due to the cross-bb usage
of the condition.

Differential Revision: https://reviews.llvm.org/D58576

llvm-svn: 354808

This is a preparatory change as I want to use emitScalarToVector() elsewhere,
and in general we want to transition to MIRBuilder instead of using BuildMI
directly.

Differential Revision: https://reviews.llvm.org/D58528

llvm-svn: 354807

#define f(y) x
#define x f(x)
int main() { x; }

This example results a compilation error since "x" in the first line was not
defined earlier. However, the macro expression printer goes to an infinite
recursion on this example.

Patch by Tibor Brunner!

Differential Revision: https://reviews.llvm.org/D57892

llvm-svn: 354806

LWG3101 - span's Container constructors need another constraint. Reviewed as https://reviews.llvm.org/D57058.

llvm-svn: 354805