This is for compatibility with GNU readobj. --arm-attributes option is
left as a hidden alias due to large number of tests using it.

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

llvm-svn: 373125

We can reuse this logic for things like fma.

llvm-svn: 373119

This reverts r373101 (git commit 72c57ec3)

llvm-svn: 373117

This reverts r373103 (git commit a524e630)

llvm-svn: 373116

We start with two separate sext's, but EarlyCSE runs before InstCombine,
so when we get them, they are a single sext, and we just ignore that.
Likewise, if we had a single sext, we don't do anything there.

llvm-svn: 373115

Adds a section to the User Guides page for articles related to building, packaging, and distributing LLVM. Includes sub-sections for CMake, Clang, and Docker.

llvm-svn: 373113

llvm-svn: 373109

[X86] Call SimplifyDemandedBits in combineGatherScatter any time the mask element is wider than i1, not just when AVX512 is disabled.

The AVX2 intrinsics can still be used when AVX512 is enabled and
those go through this path. So we should simplify them.

llvm-svn: 373108

[X86] Add test case to show failure to perform SimplifyDemandedBits on mask of avx2 gather intrinsics when avx512 is enabled.

llvm-svn: 373107

Summary:
This is valid for any `sext` bitwidth pair:
```
Processing /tmp/opt.ll..

----------------------------------------
  %signed = sext %y
  %r = shl %x, %signed
  ret %r
=>
  %unsigned = zext %y
  %r = shl %x, %unsigned
  ret %r
  %signed = sext %y

Done: 2016
Optimization is correct!
```

(This isn't so for funnel shifts, there it's illegal for e.g. i6->i7.)

Main motivation is the C++ semantics:
```
int shl(int a, char b) {
    return a << b;
}
```
ends as
```
  %3 = sext i8 %1 to i32
  %4 = shl i32 %0, %3
```
https://godbolt.org/z/0jgqUq
which is, as this shows, too pessimistic.

There is another problem here - we can only do the fold
if sext is one-use. But we can trivially have cases
where several shifts have the same sext shift amount.
This should be resolved, later.

Reviewers: spatel, nikic, RKSimon

Reviewed By: spatel

Subscribers: efriedma, hiraditya, nlopes, llvm-commits

Tags: #llvm

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

llvm-svn: 373106

This test fails when machine dominator tree verifier is run.
Needs more investigation, as this is not a new failure.

llvm-svn: 373103

Summary: This is a cleanup patch for MachineDominatorTree. It would be an NFC, except for replacing custom DomTree verification with the generic one.

Reviewers: tstellar, tpr, nhaehnle, arsenm, NutshellySima, grosser, hliao

Reviewed By: arsenm

Subscribers: wdng, hiraditya, llvm-commits

Tags: #llvm

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

llvm-svn: 373101

llvm-svn: 373100

The static analyzer is warning about a potential null dereference, but we should be able to use cast<> directly and if not assert will fire for us.

llvm-svn: 373099

These two test cases use -march=systemz instead of a triple. In
particular, the used file format is then based on the default host
triple. This leads to different behaviour on different platforms.

The SystemZ implementation uses the integrated assembler for a
long time now. The mature-mc-support test can be fully enabled.

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

llvm-svn: 373098

FunctionImportGlobalProcessing::processGlobalForThinLTO - silence static analyzer dyn_cast<FunctionSummary> null dereference warning. NFCI.

The static analyzer is warning about a potential null dereference, but we should be able to use cast<FunctionSummary> directly and if not assert will fire for us.

llvm-svn: 373097

The new names for FPRs ensure that the Register values within the same class are
enumerated consecutively (the order is determined by the `LessRecordRegister`
function object). Where there were tables mapping between 32- and 64-bit FPRs
(and vice versa) this patch replaces them with Register arithmetic. The
enumeration order between different register classes is expected to continue to
be arbitrary, although it does impact the conversion from the (overloaded) asm
FPR names to Register values, and therefore might require updates to the target
if the sorting algorithm is changed. Static asserts were added to ensure that
changes to the ordering that would impact the current implementation are
detected.

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

llvm-svn: 373096

The static analyzer is warning about a potential null dereference, but we should be able to use cast<StructType> directly and if not assert will fire for us.

llvm-svn: 373095

Summary of changes:

refactored code for better readability and future improvements;
fixed bug 41281: https://bugs.llvm.org/show_bug.cgi?id=41281

Reviewers: artem.tamazov, arsenm

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

llvm-svn: 373094

Abandon describing of loaded values due to safety concerns. Loaded
values are described as derefed memory location at caller point.
At callee we can unintentionally change that memory location which
would lead to different entry being printed value before and after
the memory location clobbering. This problem is described in
llvm.org/PR43343.

Patch by Nikola Prica

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

llvm-svn: 373089

SnippetRepetitorTest.cpp:66:27: error: declaration of ‘std::unique_ptr<llvm::Module> llvm::exegesis::{anonymous}::X86SnippetRepetitorTest::Module’ [-fpermissive]
   std::unique_ptr<Module> Module;

llvm-svn: 373087

llvm-svn: 373086

llvm-svn: 373085

Summary:
An erroneously negated if-statement by an earlier (March 2019) bugfix left phi replacement/simplification under optimizeMemoryInst()  in CodeGenPrepare largely inactivated. The error was found when csmith found that the same assert as in the original bug report could still be triggered in a different way. This patch fixes the bugfix. The original bug was:
 https://bugs.llvm.org/show_bug.cgi?id=41052
... and the previous fix was D59358.

Reviewers: aprantl, skatkov

Reviewed By: skatkov

Subscribers: hiraditya, llvm-commits

Tags: #llvm

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

llvm-svn: 373084

Summary:
Before this change the Executable function was made by duplicating the
snippet. This change adds a --repetion-mode={loop|duplicate} flag that
allows choosing between this behaviour and wrapping the snippet instructions
in a loop.

The new mode can help measurements when the snippet fits in the DSB by
short-cirtcuiting decoding. The loop adds a dec + jmp to the measurements, but
since these are not part of the critical path, they execute in parallel
with the measured code and do not impact measurements in practice.

Overview of the change:
 - New SnippetRepetitor abstraction that handles repeating the snippet.
   The assembler delegates repeating the instructions to this class.
 - ExegesisTarget learns how to decrement loop counter and jump.
 - Some refactoring of the assembler into FunctionFiller/BasicBlockFiller.

Reviewers: gchatelet

Subscribers: mgorny, tschuett, llvm-commits

Tags: #llvm

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

llvm-svn: 373083

llvm-svn: 373081

This relands r373029, reverted in 373033, because r373028 relanded in r373066.

llvm-svn: 373070

Use different data types for some simple loops.

llvm-svn: 373064

llvm-svn: 373063

D64572 / rL365818 changed the way that the file paths were collected, which meant we lost the file pattern expansion necessary when working with DOS command prompt

llvm-svn: 373062

This caused severe compile-time regressions, see PR43455.

> Modern processors predict the targets of an indirect branch regardless of
> the size of any jump table used to glean its target address.  Moreover,
> branch predictors typically use resources limited by the number of actual
> targets that occur at run time.
>
> This patch changes the semantics of the option `-max-jump-table-size` to limit
> the number of different targets instead of the number of entries in a jump
> table.  Thus, it is now renamed to `-max-jump-table-targets`.
>
> Before, when `-max-jump-table-size` was specified, it could happen that
> cluster jump tables could have targets used repeatedly, but each one was
> counted and typically resulted in tables with the same number of entries.
> With this patch, when specifying `-max-jump-table-targets`, tables may have
> different lengths, since the number of unique targets is counted towards the
> limit, but the number of unique targets in tables is the same, but for the
> last one containing the balance of targets.
>
> Differential revision: https://reviews.llvm.org/D60295

llvm-svn: 373060

Summary:
The const-correctness of match() was fixed in rL372764, which allows
such static Regex objects to be marked const.

Reviewers: thopre

Reviewed By: thopre

Subscribers: llvm-commits

Tags: #llvm

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

llvm-svn: 373058

llvm-svn: 373055

Summary:
This is patch is part of a series to introduce an Alignment type.
See this thread for context: http://lists.llvm.org/pipermail/llvm-dev/2019-July/133851.html
See this patch for the introduction of the type: https://reviews.llvm.org/D64790

Reviewers: courbet

Subscribers: hiraditya, llvm-commits

Tags: #llvm

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

llvm-svn: 373054

Happens only when the mve.fp subtarget feature is enabled:

$ llvm-mc -triple thumbv8.1m.main -mattr=+mve.fp,+8msecext -disassemble <<< "0x9f,0xec,0x08,0x0b"
  .text
  vldmia  pc, {d0, d1, d2, d3}
$ llvm-mc -triple thumbv8.1m.main -mattr=+8msecext -disassemble <<< "0x9f,0xec,0x08,0x0b"
  .text
  vscclrm {d0, d1, d2, d3, vpr}

Assembling returns the correct encoding with or without mve.fp:

$ llvm-mc -triple thumbv8.1m.main -mattr=+mve.fp,+8msecext -show-encoding <<< "vscclrm {d0-d3, vpr}"
  .text
  vscclrm {d0, d1, d2, d3, vpr}   @ encoding: [0x9f,0xec,0x08,0x0b]
$ llvm-mc -triple thumbv8.1m.main -mattr=+8msecext -show-encoding <<< "vscclrm {d0-d3, vpr}"
  .text
  vscclrm {d0, d1, d2, d3, vpr}   @ encoding: [0x9f,0xec,0x08,0x0b]

The problem seems to be in the TableGen description of VSCCLRMD.
The least significant bit should be set to zero.

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

llvm-svn: 373052

Summary:
Right now latency generation can incorrectly select the scratch register
as a dependency-carrying register.
 - Move the logic for preventing register selection from Uops
   implementation to common SnippetGenerator class.
 - Aliasing detection now takes a set of forbidden registers just like
   random register assignment does.

Reviewers: gchatelet

Subscribers: tschuett, llvm-commits

Tags: #llvm

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

llvm-svn: 373048

hasDedicatedExits.

For the compile time problem described in https://reviews.llvm.org/D67359,
turns out the root cause is there are many duplicates in ExitBlocks so
the algorithm complexity of hasDedicatedExits gets very high. If we remove
the duplicates, the compile time issue is gone.

Thanks to Philip Reames for raising a good question and it leads me to
find the root cause.

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

llvm-svn: 373045

exits"

Get a better approach in https://reviews.llvm.org/D68107 to solve the problem.
Revert the initial patch and will commit the new one soon.

This reverts commit rL372990.

llvm-svn: 373044

Summary:
As specified at
https://github.com/WebAssembly/simd/blob/master/proposals/simd/SIMD.md#bitwise-and-not

Reviewers: aheejin

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

Tags: #llvm

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

llvm-svn: 373041

Summary:
As specified at
https://github.com/webassembly/simd/blob/master/proposals/simd/SIMD.md#load-and-extend.
These instructions are behind the unimplemented-simd128 target feature
for now because they have not been implemented in V8 yet.

Reviewers: aheejin

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

Tags: #llvm

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

llvm-svn: 373040