It seems virtually everyone who tries to do LTO build with Clang and
LLD was hit by a mistake to forget using llvm-ar command to create
archive files. I wasn't an exception. Since this is an annoying common
issue, it is probably better to handle that gracefully rather than
reporting an error and tell the user to redo build with different
configuration.

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

llvm-svn: 302083

llvm-svn: 302082

ArchKind is passed to the function, but it's also a type.

llvm-svn: 302081

llvm-svn: 302080

llvm-svn: 302079

Otherwise, each CPU has to manually specify the extensions it supports,
even though they have to be a superset of the base arch extensions.
And when there's redundant data there's stale data, so most of the CPUs
lie about the features they support (almost none lists AEK_FP).

Instead, do the saner thing: add the optional extensions on top of the
base extensions provided by the architecture.

The ARM TargetParser has the same behavior.

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

llvm-svn: 302078

That's only a required extension as of v8.1a.

Remove it from the "generic" CPU as well: it should only support the
base ISA (and binutils agrees).

Also unify the MC tests into crc.s and arm64-crc32.s

llvm-svn: 302077

Summary:
It's not safe to assume that atexit handlers can be run once the app crashed.

Patch by Jochen Eisinger.

Reviewers: kcc, vitalybuka

Subscribers: llvm-commits

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

llvm-svn: 302076

Patch by Jyotsna Verma.

llvm-svn: 302073

LLVM-IR names are commonly available in debug builds, but often not in release
builds. Hence, using LLVM-IR names to identify statements or memory reference
results makes the behavior of Polly depend on the compile mode. This is
undesirable. Hence, we now just number the statements instead of using LLVM-IR
names to identify them (this issue has previously been brought up by Zino
Benaissa).

However, as LLVM-IR names help in making test cases more readable, we add an
option '-polly-use-llvm-names' to still use LLVM-IR names. This flag is by
default set in the polly tests to make test cases more readable.

This change reduces the time in ScopInfo from 32 seconds to 2 seconds for the
following test case provided by Eli Friedman <efriedma@codeaurora.org> (already
used in one of the previous commits):

  struct X { int x; };
  void a();
  #define SIG (int x, X **y, X **z)
  typedef void (*fn)SIG;
  #define FN { for (int i = 0; i < x; ++i) { (*y)[i].x += (*z)[i].x; } a(); }
  #define FN5 FN FN FN FN FN
  #define FN25 FN5 FN5 FN5 FN5
  #define FN125 FN25 FN25 FN25 FN25 FN25
  #define FN250 FN125 FN125
  #define FN1250 FN250 FN250 FN250 FN250 FN250
  void x SIG { FN1250 }

For a larger benchmark I have on-hand (10000 loops), this reduces the time for
running -polly-scops from 5 minutes to 4 minutes, a reduction by 20%.

The reason for this large speedup is that our previous use of printAsOperand
had a quadratic cost, as for each printed and unnamed operand the full function
was scanned to find the instruction number that identifies the operand.

We do not need to adjust the way memory reference ids are constructured, as
they do not use LLVM values.

Reviewed by: efriedma

Tags: #polly

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

llvm-svn: 302072

llvm-svn: 302069

llvm-svn: 302068

It doesn't matter what binding we store in a non-UsedInRegularObj undefined
symbol because we should reset it when we see a real undefined symbol in
a combined LTO object. The fact that we weren't doing so before is a bug
(PR32899) which is now fixed.

llvm-svn: 302067

A bot had "-LTO" in its working directory, which matched the regex used in this
test. Since the arg is quoted, we can exploit that instead. Still broken if
there's a path with a quote in, but I think that's pretty niche.

llvm-svn: 302066

We were ignoring strong undefined symbols if they followed weak ones.

Fixes pr32899.

llvm-svn: 302065

[asan] print the 'unexpected format specifier in printf interceptor' warning just once (came up in https://github.com/google/oss-fuzz/pull/562). Not touching a similar scanf warning -- for some reason it does not fire for me. 

llvm-svn: 302064

llvm-svn: 302063

Adrian requested that we break things down to make things clean in the DWARFVerifier. This patch breaks everything down into nice individual functions and cleans up the code quite a bit and prepares us for the next round of verifiers.

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

llvm-svn: 302062

llvm-svn: 302061

Summary:
Do three things to help with that:
- Add AttributeList::FirstArgIndex, which is an enumerator currently set
  to 1. It allows us to change the indexing scheme with fewer changes.
- Add addParamAttr/removeParamAttr. This just shortens addAttribute call
  sites that would otherwise need to spell out FirstArgIndex.
- Remove some attribute-specific getters and setters from Function that
  take attribute list indices.  Most of these were only used from
  BuildLibCalls, and doesNotAlias was only used to test or set if the
  return value is malloc-like.

I'm happy to split the patch, but I think they are probably easier to
review when taken together.

This patch should be NFC, but it sets the stage to change the indexing
scheme to this, which is more convenient when indexing into an array:
  0: func attrs
  1: retattrs
  2...: arg attrs

Reviewers: chandlerc, pete, javed.absar

Subscribers: david2050, llvm-commits

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

llvm-svn: 302060

I should've staged this with my last commit.

llvm-svn: 302059

Summary:
Cloning basic blocks in the loop for runtime loop unroller depends on loop being
in rotated form (i.e. loop latch target is the exit block).
Assert that this is true, so that callers of runtime loop unroller pass in
canonical loops.
The single caller of this function has that check recently added:
https://reviews.llvm.org/rL301239

Reviewers: davide

Subscribers: llvm-commits

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

llvm-svn: 302058

llvm-svn: 302057

llvm-svn: 302056

  . there should be no runtime relocation inside the bpf function.
  . relocation supported here mostly for debugging.
  . a test case is added.

Signed-off-by: Yonghong Song <yhs@fb.com>
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
llvm-svn: 302055

This reverts commit r302025.

clang and lld need to be updated too so they don't break with this patch.

llvm-svn: 302054

The raw CodeView format references strings by "offsets", but it's
confusing what table the offset refers to.  In the case of line
number information, it's an offset into a buffer of records,
and an indirection is required to get another offset into a
different table to find the final string.  And in the case of
checksum information, there is no indirection, and the offset
refers directly to the location of the string in another buffer.

This would be less confusing if we always just referred to the
strings by their value, and have the library be smart enough
to correctly resolve the offsets on its own from the right
location.

This patch makes that possible.  When either reading or writing,
all the user deals with are strings, and the library does the
appropriate translations behind the scenes.

llvm-svn: 302053

llvm-readobj hand rolls some CodeView parsing code for string
tables, so this patch updates it to re-use some of the newly
introduced parsing code in LLVMDebugInfoCodeView.

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

llvm-svn: 302052

I was worried we might replace a mul with a mul+shift even if there were later
uses. Turns out to be unfounded but I'd just as well add an actual test for it.

llvm-svn: 302051

This patch allows the Swift compiler to emit calls to `__tsan_external_write` before starting any modifying access, which will cause TSan to detect races on arrays, dictionaries and other classes defined in non-instrumented modules. Races on collections from the Swift standard library and user-defined structs and a frequent cause of subtle bugs and it's important that TSan detects those on top of existing LLVM IR instrumentation, which already detects races in direct memory accesses.

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

llvm-svn: 302050

llvm-svn: 302049

llvm-svn: 302048

Summary: Do the transform when the carry isn't used. It's a pattern exposed when legalizing large integers.

Reviewers: jyknight, nemanjai, mkuper, spatel, RKSimon, zvi, bkramer

Subscribers: llvm-commits

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

llvm-svn: 302047

The commit caused the following two buildbot failures:

    Clang :: Misc/error-limit-multiple-notes.cpp
    Clang :: Misc/error-limit.c

llvm-svn: 302046

trace-pc doesn't work, but trace-pc-guard does. *shrug*

llvm-svn: 302045

Adrian requested we create a DWARFVerifier.cpp file to contain all of the DWARF verification stuff. This change simply moves the functionality over into DWARFVerifier.h and DWARFVerifier.cpp, renames the DWARFVerifier methods to start with lower case, and switches DWARFContext.cpp over to using the new functionality.

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

llvm-svn: 302044

llvm-svn: 302043

This was reverted due to a "missing" file, but in reality
what happened was that I renamed a file, and then due to
a merge conflict both the old file and the new file got
added to the repository.  This led to an unused cpp file
being in the repo and not referenced by any CMakeLists.txt
but #including a .h file that wasn't in the repo.  In an
even more unfortunate coincidence, CMake didn't report the
unused cpp file because it was in a subdirectory of the
folder with the CMakeLists.txt, and not in the same directory
as any CMakeLists.txt.

The presence of the unused file was then breaking certain
tools that determine file lists by globbing rather than
by what's specified in CMakeLists.txt

In any case, the fix is to just remove the unused file from
the patch set.

llvm-svn: 302042

This patch adds support for the the LightWeight Profiling (LWP) instructions which are available on all AMD Bulldozer class CPUs (bdver1 to bdver4).

Reapplied - this time without changing line endings of existing files.

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

llvm-svn: 302041

Currently several places assume the VAL member is always at least the same size as pVal. In particular for a memcpy in the move assignment operator. While this is a true assumption, it isn't good practice to assume this.

This patch gives the union a name so we can write the memcpy in terms of the union itself. This also adds a similar memcpy to the move constructor where we previously just copied using VAL directly.

This patch is mostly just a mechanical addition of the U in front of VAL and pVAL everywhere. But several constructors had to be modified since we can't directly initializer a field of named union from the initializer list.

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

llvm-svn: 302040