/code/llvm-project/llvm/unittests/ExecutionEngine/Orc/RTDyldObjectLinkingLayerTest.cpp:260:38: error: lambda capture 'this' is not used [-Werror,-Wunused-lambda-capture]
                                    [this](decltype(ObjLayer)::ObjHandleT,

llvm-svn: 314454

This causes the gcc sanitizer buildbot to timeout.

This reverts commit 81f388fe570e5b6460dd5bc9b9a36b72714eeb68.

llvm-svn: 314453

Currently AMDGPU inline asm only allow v and s as register names in constraints.

This patch allows the following register names in constraints: (n, m is unsigned integer, n < m)

v

s

{vn} or {v[n]}

{sn} or {s[n]}

{S} , where S is a special register name

{v[n:m]}

{s[n:m]}

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

llvm-svn: 314452

In setupEntryBlockAndCallSites in CodeGen/SjLjEHPrepare.cpp,
we fetch and store the actual frame pointer, but on return via
the longjmp intrinsic, it always was restored into the r7 variable.

On windows, the frame pointer should be restored into r11 instead of r7.

On Darwin (where sjlj exception handling is used by default), the frame
pointer is always r7, both in arm and thumb mode, and likewise, on
windows, the frame pointer always is r11.

On linux however, if sjlj exception handling is enabled (which it isn't
by default), libcxxabi and the user code can be built in differing modes
using different registers as frame pointer. Therefore, when restoring
registers on a platform where we don't always use the same register
depending on code mode, restore both r7 and r11.

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

llvm-svn: 314451

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

llvm-svn: 314450

llvm-svn: 314449

The multiply lowering on some of the tests can take advantage of the vpmovwb to simplify the truncate.

llvm-svn: 314448

We aren't do any in register extends here so we should be able to just the target independent nodes directly and allow them to be lowered as necessary.

llvm-svn: 314447

[X86] Move a setOperation action for ISD::TRUNCATE near another one in the same if. Remove one that is redundant with another subtarget features.

llvm-svn: 314446

Summary:
Completion results look much nicer without them.
Informative qualifiers are stored for every method from a base class, even when
calling those methods does not require any qualifiers. For example,
    struct Foo { int foo(); };
    struct Bar : Foo { };
    void test() { Bar(). // Completion item label was 'Foo::foo' before,
                         // but inserted text was simply 'foo'.
                         // We now simply show 'foo' in completion item label.

They effectively cluttered the completion list without providing much value.

Reviewers: bkramer, krasimir, rwols

Reviewed By: rwols

Subscribers: klimek, cfe-commits

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

llvm-svn: 314445

to have child entries describing the template parameters.  This will
be on by default for SCE tuning.

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

llvm-svn: 314444

llvm-svn: 314443

llvm-svn: 314442

The link in the "Shadow memory range interleaves with an existing
memory mapping" error message was pointing to the wrong bug.

llvm-svn: 314441

We were not subtracting its size, causing it to overlap with section
data.

Fixes PR34750.

llvm-svn: 314440

This patch implements the dwarfdump option --find=<name>.  This option
looks for a DIE in the accelerator tables and dumps it if found.  This
initial patch only adds support for .apple_names to keep the review
small, adding the other sections and pubnames support should be
trivial though.

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

llvm-svn: 314439

Bug found by Stefan Granitz. Thanks Stefan!

llvm-svn: 314436

JumpThreading now preserves dominance and lazy value information across the
entire pass.  The pass manager is also informed of this preservation with
the goal of DT and LVI being recalculated fewer times overall during
compilation.

This change prepares JumpThreading for enhanced opportunities; particularly
those across loop boundaries.

Patch by: Brian Rzycki <b.rzycki@samsung.com>,
          Sebastian Pop <s.pop@samsung.com>

Differential revision: https://reviews.llvm.org/D37528

llvm-svn: 314435

This would have found the issues with r313697.

The problem was that that commit mixed the content of different
.eh_frame sections. Unfortunately we had no tests looking inside the
fdes.

llvm-svn: 314433

Summary: If we have BWI instructions we can widen to v32i16 to do the multiply instead of splitting.

Reviewers: RKSimon, spatel, zvi

Reviewed By: zvi

Subscribers: llvm-commits

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

llvm-svn: 314432

Summary:
Adds a fallback mode to procmaps when the symbolizer
fails to locate a module for a given address by using
dl_iterate_phdr.

Reviewers: kubamracek, rnk, vitalybuka, eugenis

Reviewed By: eugenis

Subscribers: srhines, llvm-commits

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

llvm-svn: 314431

Summary:
Lowering never creates X86ISD::UMUL for 8-bit types. X86ISD::UMUL8 is used instead. If X86ISD::UMUL 8-bit were ever used it would crash.

DAGCombiner replaces UMUL_LOHI/SMUL_LOHI with a wider MUL and a shift if the type twice as wide is legal. So we should never see i8 UMUL_LOHI/SMUL_LOHI. In fact I think there was a bug in part of the i8 code. Similar is true for i16 though without the bug.

Reviewers: RKSimon, spatel, zvi

Reviewed By: zvi

Subscribers: llvm-commits

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

llvm-svn: 314430

Previously we were using one of the subvector indices twice. The included test case causes an assert without this change.

Thanks to Simon Pilgrim for catching this.

llvm-svn: 314429

The SystemZ compare-and-swap instructions already provide the "success"
indication via a condition-code value, so the default expansion of those
operations generates an unnecessary extra comparsion.

llvm-svn: 314428

llvm-svn: 314427

This patch adds a check to the DWARF verifier to detect CUs without a
unit DIE.

Differential revision: https://reviews.llvm.org/D38363

llvm-svn: 314426

llvm-svn: 314425

llvm-svn: 314424

llvm-svn: 314423

llvm-svn: 314422

This patch disables codegen support for branch likely instructions to
address a potential bug. These branches were unselectable as
they had the same patterns as the normal branches but came after them
when ISel was concerned.

The branch likely instructions were marked as having no delay
slots when they have annulling delay slots. The delay slot filler
does not currently handle annulling delay slot branches, so this
would lead to wrong codegen if these branches were generated.

Reviewers: atanasyan, nitesh.jain

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

llvm-svn: 314421

llvm-svn: 314420

Summary:
Add a document which describes:

- GEMM performance comparison.
- An experiment that measures the compile time impact
  of enabling Polly when compiling LLVM+Clang+Polly.

Contributed-by: Theodoros <Theodoridis&lt;theodoros.theodoridis@inf.ethz.ch>
Differential Revision: https://reviews.llvm.org/D38330

llvm-svn: 314419

llvm-svn: 314418

This commit adds the test file before codegen changes as requested in
D38161 to make it easier to see the difference.

llvm-svn: 314416

dlclose itself might touch it, so better return it to the state it was
before. I don't know how to create a test for this as it would require
chaning dlclose itself.

llvm-svn: 314415

Summary:
A DBG_VALUE that is referring to a physical register is
valid up until the next def of the register, or the end
of the basic block that it belongs to.

LiveDebugVariables is computing live intervals (slot index
ranges) for DBG_VALUE instructions, before regalloc, in order
to be able to re-insert DBG_VALUE instructions again after
regalloc. When the DBG_VALUE is mapping a variable to a
physical register we do not need to compute the range. We
should simply re-insert the DBG_VALUE at the start position.

The problem that was found, resulting in this patch, was a
situation when the DBG_VALUE was the last real use of the
physical register. The computeIntervals/extendDef methods
extended the range to cover the whole basic block, even though
the physical register very well could be allocated to some
virtual register inside the basic block. So the extended
range could not be trusted.

This patch is a preparation for https://reviews.llvm.org/D38229,
where the goal is to insert DBG_VALUE after each new definition
of a variable, even if the virtual registers that the variable
was connected to has been coalesced into using the same physical
register (e.g. due to two address instructions). For more info
see https://bugs.llvm.org/show_bug.cgi?id=34545

Reviewers: aprantl, rnk, echristo

Reviewed By: aprantl

Subscribers: Ka-Ka, llvm-commits

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

llvm-svn: 314414

The second argument for Allocator::Deallocate is the number of elements,
not the size of a single element. In asan mode specifying a large number
of elements poisoned random memory regions, leading to crashes
everywhere.

llvm-svn: 314413

r314375 privatized Loop's constructor and replaced it with an Allocator.

llvm-svn: 314412

Summary:
This allows sharing the lattice value code between LVI and SCCP (D36656). 

It also adds a `satisfiesPredicate` function, used by D36656.

Reviewers: davide, sanjoy, efriedma

Reviewed By: sanjoy

Subscribers: mgorny, llvm-commits

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

llvm-svn: 314411