Add a note about legacy FunctionPassManager to the LLVM tutorial.

It seems to confuse some people, worth adding a warning to the tutorial
to elaborate and suggest using `llvm::legacy::FunctionPassManager` for
now. Not a perfect solution but hopefully will avoid confusion
in the meantime.

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

llvm-svn: 355930

I recently discovered a bug in llvm-cxxfilt introduced in r353743 but
was fixed later incidentally due to r355031. Specifically, llvm-cxxfilt
was attempting to call .back() on an empty string any time there was a
new line in the input. This was causing a crash in my debug builds only.
This patch simply adds a test that explicitly tests that llvm-cxxfilt
handles empty lines correctly. It may pass under release builds under
the broken behaviour, but it fails at least in debug builds.

Reviewed by: mattd

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

llvm-svn: 355929

[FileCheck]Remove assertions that prevent matching an empty string at file start before CHECK-NEXT/SAME

This patch removes two assertions that were preventing writing of a test
that checked an empty line followed by some text. For example:

CHECK: {{^$}}
CHECK-NEXT: foo()

The assertion was because the current location the CHECK-NEXT was
scanning from was the start of the buffer. A similar issue occurred with
CHECK-SAME. These assertions don't protect against anything, as there is
already an error check that checks that CHECK-NEXT/EMPTY/SAME don't
appear first in the checks, and the following code works fine if the
pointer is at the start of the input.

Reviewed by: probinson, thopre, jdenny
Differential Revision: https://reviews.llvm.org/D58784

llvm-svn: 355928

Reviewers: beanz, arphaman, EricWF

Subscribers: dberris, mgorny, jkorous, dexonsmith, jdoerfert, cfe-commits

Tags: #clang

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

llvm-svn: 355927

Targets can potentially emit more efficient code if they know address
computations never overflow. For example ILP32 code on AArch64 (which only has
64-bit address computation) can ignore the possibility of overflow with this
extra information.

llvm-svn: 355926

llvm-svn: 355925

Summary:
1. \t => '  '
2. test commit access

Reviewers: Higuoxing, liangdzou

Reviewed By: Higuoxing, liangdzou

Subscribers: kristina, llvm-commits

Tags: #llvm

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

llvm-svn: 355924

Summary:
This CL implements the checksumming functions. This departs from the
current Scudo code in one aspect: the software version is no longer
CRC32 but a BSD checksum. This is because the software CRC32 was too
impactful in terms of performances, the BSD checksum has no array
lookup which is better (and saves 1KB of data).

As with the current version, we only flip the CRC compiler flag for
a single compilation unit by default, to allow for a library compiled
with HW CRC32 to work on a system without HW CRC32.

There is some platform & hardware specific code in those files, but
since departs from a mere platform split, it felt right to me to have
it that way.

Reviewers: morehouse, eugenis, vitalybuka, hctim, mcgrathr

Reviewed By: morehouse

Subscribers: mgorny, delcypher, jfb, jdoerfert, #sanitizers, llvm-commits

Tags: #llvm, #sanitizers

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

llvm-svn: 355923

Summary: This helps resolve https://bugs.llvm.org/show_bug.cgi?id=31564

Reviewers: jhenderson, grimar

Reviewed By: jhenderson

Subscribers: rupprecht, llvm-commits

Tags: #llvm

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

llvm-svn: 355922

The code might intend to replace puts("") with putchar('\n') even if the
return value is used. It failed because use_empty() was used to guard
the whole block. While returning '\n' (putchar('\n')) is technically
correct (puts is only required to return a nonnegative number on
success), doing this looks weird and there is really little benefit to
optimize puts whose return value is used. So don't do that.

llvm-svn: 355921

This was found when we generated COPY from G8RC to F8RC in
EmitInstrWithCustomInserter without checking proper architecture,
we silently generated mtvsrd, which require P8 and up.

This is a NFC patch to add assert when we call copyPhysReg, in case
someone accidentally generate COPY between G8RC to F8RC for P7 and
below.

llvm-svn: 355920

All of LLVM builds with CMake, so it doesn't make sense to maintain a
separate set of build files just for pstl.

Thanks to Thomas Rodgers for the patch.
Differential Revision: https://reviews.llvm.org/D59111

llvm-svn: 355919

Previously, we'd be performing math on `#define PSTL_VERSION NNN` instead
of just `NNN`. It seems like older CMakes didn't complain, but newer
CMakes do complain because it doesn't make sense.

llvm-svn: 355918

llvm-svn: 355917

As for OpenCL C, we need to allow using printf and toolchain variadic
functions (prefixed by "__") in C++ mode.

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

llvm-svn: 355915

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

llvm-svn: 355914

Revert rL355906: [SLP] Remove redundancy of performing operand reordering twice: once in buildTree() and later in vectorizeTree().

This is a refactoring patch that removes the redundancy of performing operand reordering twice, once in buildTree() and later in vectorizeTree().
To achieve this we need to keep track of the operands within the TreeEntry struct while building the tree, and later in vectorizeTree() we are just accessing them from the TreeEntry in the right order.

This patch is the first in a series of patches that will allow for better operand reordering across chains of instructions (e.g., a chain of ADDs), as presented here: https://www.youtube.com/watch?v=gIEn34LvyNo

Patch by: @vporpo (Vasileios Porpodas)

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

Reverted due to buildbot failures that I don't have time to track down.

llvm-svn: 355913

llvm-svn: 355912

Buildbot breaks when LLVm is compiled with memory sanitizer.

WARNING: MemorySanitizer: use-of-uninitialized-value
    #0 0xa3d16d8 in getMacroNameAndPrintExpansion(blahblah)
                             lib/StaticAnalyzer/Core/PlistDiagnostics.cpp:903:11
llvm-svn: 355911

This teaches LLD to report visibility when showing undefined symbol errors
and fixes https://bugs.llvm.org/show_bug.cgi?id=40770.

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

llvm-svn: 355909

Because I don't understand svn.

llvm-svn: 355908

Created a test/CodeGen/ARM/ParallelDSP folder.

llvm-svn: 355907

[SLP] Remove redundancy of performing operand reordering twice: once in buildTree() and later in vectorizeTree().

This is a refactoring patch that removes the redundancy of performing operand reordering twice, once in buildTree() and later in vectorizeTree().
To achieve this we need to keep track of the operands within the TreeEntry struct while building the tree, and later in vectorizeTree() we are just accessing them from the TreeEntry in the right order.

This patch is the first in a series of patches that will allow for better operand reordering across chains of instructions (e.g., a chain of ADDs), as presented here: https://www.youtube.com/watch?v=gIEn34LvyNo

Patch by: @vporpo (Vasileios Porpodas)

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

llvm-svn: 355906

llvm-svn: 355905

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

llvm-svn: 355904

When there is a functor-like macro which is passed as parameter to another
"function" macro then its parameters are not listed at the place of expansion:

#define foo(x) int bar() { return x; }
#define hello(fvar) fvar(0)
hello(foo)
int main() { 1 / bar(); }

Expansion of hello(foo) asserted Clang, because it expected an l_paren token in
the 3rd line after "foo", since it is a function-like token.

Patch by Tibor Brunner!

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

llvm-svn: 355903

Summary:
Add support for immediate operand in S_ENDPGM

Change-Id: I0c56a076a10980f719fb2a8f16407e9c301013f6

Reviewers: alexshap

Subscribers: qcolombet, arsenm, kzhuravl, jvesely, wdng, nhaehnle, yaxunl, tpr, t-tye, eraman, arphaman, Petar.Avramovic, llvm-commits

Tags: #llvm

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

llvm-svn: 355902

This is addressing the issue that we're not modeling the cost of clib functions
in TTI::getIntrinsicCosts and thus we're basically addressing this fixme:
    
// FIXME: This is wrong for libc intrinsics.

To enable analysis of clib functions, we not only need an intrinsic ID and
formal arguments, but also the actual user of that function so that we can e.g.
look at alignment and values of arguments. So, this is the initial plumbing to
pass the user of an intrinsinsic on to getCallCosts, which queries
getIntrinsicCosts.

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

llvm-svn: 355901

These two values correspond to the 'Empty' and 'Tombstone' special
keys defined by DenseMapInfo<int64_t>, which means that neither one
can be used as a key in DenseMap<int64_t, anything>. Hence, if you try
to use either of those values as an int literal, IntInit::get() fails
an assertion when it tries to insert them into its static cache of
int-literal objects.

Fixed by replacing the DenseMap with a std::map, which doesn't intrude
on the space of legal values of the key type.

Reviewers: nhaehnle, hfinkel, javedabsar, efriedma

Reviewed By: efriedma

Subscribers: fhahn, efriedma, hiraditya, llvm-commits

Tags: #llvm

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

llvm-svn: 355900

These are closely modeled on similar tests for the ilp32 ABI. Like those
tests, we group together tests that should be common cross lp64, lp64+lp64f,
and lp64+lp64f+lp64d ABIs.

llvm-svn: 355899

Summary:
This patch marks the inline namespaces from DWARF as inline and also ensures that looking
up declarations now follows the lookup rules for inline namespaces.

Reviewers: aprantl, shafik, serge-sans-paille

Reviewed By: aprantl

Subscribers: eraman, jdoerfert, lldb-commits

Tags: #c_modules_in_lldb, #lldb

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

llvm-svn: 355897

Summary:
I'm trying to push D59198 but it seems that `git-llvm push` can't handle the fact
that I add a new directory in the patch:

```
> git llvm push -n
Pushing 1 commit:
  e7c0a9bd136 Correctly look up declarations in inline namespaces
Traceback (most recent call last):
  File "llvm/utils/git-svn//git-llvm", line 431, in <module>
    args.func(args)
  File "llvm/utils/git-svn//git-llvm", line 385, in cmd_push
    clean_svn(svn_root)
  File "llvm/utils/git-svn//git-llvm", line 201, in clean_svn
    os.remove(os.path.join(svn_repo, filename))
IsADirectoryError: [Errno 21] Is a directory: '.git/llvm-upstream-svn/lldb/trunk/packages/Python/lldbsuite/test/expression_command/inline-namespace'
```

This patch just uses shutil to delete the directory instead of trying to use `os.remove`
which only works for files.

Reviewers: mehdi_amini, jlebar

Reviewed By: jlebar

Subscribers: llvm-commits

Tags: #llvm

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

llvm-svn: 355896

Typo `we we're` => `we were` in the pass EarlyCSE

Patch by liangdzou (Liang ZOU)

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

llvm-svn: 355895

On Darwin targets, llvm-ar creates a Darwin format archive by default,
which ld.lld can't read, so it was printing an unexpected error.

llvm-svn: 355894

The Live bit is already set to false by SectionBase.

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

llvm-svn: 355893

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

llvm-svn: 355892

This change introduces support for object files in addition to static
and shared libraries which were already supported which requires
changing the type of the argument from boolean to an enum.

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

llvm-svn: 355891

Summary:
This is a test case to go with D44406 which added FlagNonTrivial to mark that a C++ record is non-trivial to support CodeView debug emission. 

While it looks like FlagTypePassByValue can imply triviality and FlagTypePassByReference can imply non-triviality that is not true. Some non-trivial cases use a combination of FlagNonTrivial and FlagTypePassByValue instead of FlagTypePassByReference. See the test cases and D44406 for discussion.

Reviewers: dblaikie, rnk, zturner

Reviewed By: dblaikie

Subscribers: jdoerfert, llvm-commits

Tags: #llvm

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

llvm-svn: 355890

Change from original commit: move test (that uses an X86 triple) into the X86
subdirectory.

Original description:
Gating vectorizing reductions on *all* fastmath flags seems unnecessary;
`reassoc` should be sufficient.

Reviewers: tvvikram, mkuper, kristof.beyls, sdesmalen, Ayal

Reviewed By: sdesmalen

Subscribers: dcaballe, huntergr, jmolloy, mcrosier, jlebar, bixia, llvm-commits

Tags: #llvm

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

llvm-svn: 355889

Hopefully gives a more readable error message for the most obvious
mistake.

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

llvm-svn: 355888