Summary:
llvm-cfi-verify (D38379) introduced a potential build failure when compiling with `-DLLVM_BUILD_LLVM_DYLIB=ON -DLLVM_LINK_LLVM_DYLIB=ON`. Specific versions of cmake seem to treat the `add_subdirectory()` rule differently. It seems as if old versions of cmake BFS these rules, adding them to the fringe for expansion later. Newer versions of cmake seem to immediately execute CMakeFiles that are present in this subdirectory.

If the subdirectory is expanded through the fringe, the globbing resultant from `llvm_add_implicit_projects()` from `cmake/modules/AddLLVM.cmake:1012` means that `tools/llvm-shlib/CMakeFile.txt` gets executed before `tools/llvm-cfi-verify/lib/CMakeFile.txt`. As the latter CMakeFile adds a new library, this expansion order means that the library files required the unit tests in `unittests/tools/llvm-cfi-verify/` are not present in the dynamic library. This causes unit tests to fail as the required functions can't be found.

This change now ensures that the libraries created by `llvm-cfi-verify` are statically linked into the unit tests. As `tools/llvm-cfi-verify/lib` no longer adds anything to `llvm-shlib`, there should be no concern about the order-of-compilation.

Reviewers: skatkov, pcc

Reviewed By: skatkov, pcc

Subscribers: llvm-commits, kcc, pcc, aheejin, vlad.tsyrklevich, mgorny

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

llvm-svn: 316059

This adds update_mir_test_checks, which updates the check lines in mir
tests. This can only update tests that start and end with .mir
currently (ie, -run-pass) but it should be sufficient for updating at
least some of the GlobalISel tests.

llvm-svn: 316057

Summary:
 If a compare instruction is same or inverse of the compare in the
 branch of the loop latch, then return a constant evolution node.
 Currently scope of evaluation is limited to SCEV computation for
 PHI nodes.

 This shall facilitate computations of loop exit counts in cases
 where compare appears in the evolution chain of induction variables.

 Will fix PR 34538
Reviewers: sanjoy, hfinkel, junryoungju

Reviewed By: junryoungju

Subscribers: javed.absar, llvm-commits

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

llvm-svn: 316054

When more than one Module is imported into the same context, such as during
an LTO build before linking the modules, ODR type uniquing may cause types
to point to a different CU. This check does not make sense in this case.

This fixes the error reported in PR34944.

https://bugs.llvm.org/show_bug.cgi?id=34944
rdar://problem/34940685

This reapplies a cleaner implementation of r316049.

llvm-svn: 316052

This reverts commit r316049.

llvm-svn: 316050

When more than one Module is imported into the same context, such as during
an LTO build before linking the modules, ODR type uniquing may cause types
to point to a different CU. This check does not make sense in this case.

This fixes the error reported in PR34944.

https://bugs.llvm.org/show_bug.cgi?id=34944
rdar://problem/34940685

llvm-svn: 316049

Otherwise they are ambiguous in MIR.

llvm-svn: 316047

Summary:
std::unordered_multimap happens to be very slow when the number of elements
grows large. On one of our internal applications we observed a 17x compile time
improvement from changing it to DenseMap.

Reviewers: mehdi_amini, serge-sans-paille, davide

Subscribers: llvm-commits

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

llvm-svn: 316045

The new scheme should match the normalization of embedded paths in
linkrepro tar files.

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

llvm-svn: 316044

Differential Revision: http://reviews.llvm.org/D39014

llvm-svn: 316037

Note that cyclone itself doesn't fuse, but newer apple chips do and we
are using cyclone as the default when targeting apple OSes.

The current code also does not capture all fusion patterns of apple CPUs
yet; I am still looking for ways to refactor the code nicely to extend
it.

llvm-svn: 316036

If the address of a local is used in a comparison, AArch64 can fold the
address-calculation into the comparison via "adds". Unfortunately, a couple of
places (both hit in this one test) are not ready to deal with that yet and just
assume the first source operand is a register.

llvm-svn: 316035

[Transforms] Fix some Clang-tidy modernize and Include What You Use warnings; other minor fixes (NFC).

llvm-svn: 316034

llvm-svn: 316033

Move the prune logic in pruneOverlaps to a new function, prune. This lets us
reuse the prune functionality. Makes the code a bit more readable. It'll also
make it easier to emit remarks/debug statements for pruned functions.

llvm-svn: 316031

We are investigating what went wrong.

llvm-svn: 316029

BigSize had a copy/paste typo in it. This fixes that.

llvm-svn: 316027

This allows us to use standard cmake utilities to point to non-system zlib
locations.

Patch by Oksana Shadura and me (D39002).

llvm-svn: 316025

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

llvm-svn: 316024

This commit moves the decrement logic for outlined functions into the class,
and makes OccurrenceCount private. It can now be accessed via
getOccurrenceCount().

This makes it more difficult to accidentally introduce bugs by incorrectly
decrementing the occurrence count on OutlinedFunctions.

llvm-svn: 316020

Cleanup to Candidate that moves all end index calculations into
Candidate.endIdx(). For the sake of consistency, StartIdx and Len are now
private members, and can be accessed with length() and startIdx() respectively.

llvm-svn: 316019

This overflow does not affect algorithm, so just suppress it.

llvm-svn: 316018

This allows us to simplify later visitVECTOR_SHUFFLE optimizations such as combineShuffleOfScalars.

Noticed whilst working on D38696

llvm-svn: 316017

Summary: Create a fuzzer for sanitizer blacklists.

Patch by: hctim

Reviewers: morehouse

Reviewed By: morehouse

Subscribers: llvm-commits, mgorny, kcc

Differential Revision: https://review.llvm.org/D38981

llvm-svn: 316014

A smarter compiler will see that these might be better without a jump table
if we're just using the constant values of the switch.

llvm-svn: 316012

llvm-svn: 316008

llvm-svn: 316006

llvm-svn: 316005

NFC.
Added the Broadwell cpu and the BROADWELL prefix to all the scheduling regression tests, as part of prepartion for a larger commit of adding all Broadwell scheduiling.

Reviewers: RKSimon, zvi, aaboud
Differential Revision: https://reviews.llvm.org/D38994

Change-Id: I54bc9065168844c107b1729fcdc1d311ce3ea0a9
llvm-svn: 315998

Summary:
ValueTracking was recognizing not all variations of clamp. Swapping of
true value and false value of select was added to fix this problem. This
change breaks the canonical form of cmp inside the matchMinMax function,
that is why additional checks for compare predicates is needed. Added
corresponding test cases.

Reviewers: spatel

Subscribers: llvm-commits

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

Patch by: Artur Gainullin <artur.gainullin@intel.com>

llvm-svn: 315992

Summary:
It seems that negative offset was accidentally allowed in D17967.
AFAICT small negative offset should be valid (always raise segfault) on all archs that I'm aware of (especially x86, which is the only one with this optimization enabled) and such case can be useful when loading hiden metadata from an object.

However, like the positive side, it should only be done within a certain limit.
For now, use the same limit on the positive side for the negative side.
A separate option can be added if needs appear.

Reviewers: mcrosier, skatkov

Reviewed By: skatkov

Subscribers: sanjoy, llvm-commits

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

llvm-svn: 315991

Summary:
Make sure the map is cleared before processing a new module. Similar to what is done on `StackMaps`.

This issue is similar to D38588, though this time for FaultMaps (on x86) rather than ARM/AArch64. Other than possible mixing of information between modules, the crash is caused by the pointers values in the map that was allocated by the bump pointer allocator that is unwinded when emitting the next file. This issue has been around since 3.8.

This issue is likely much harder to write a test for since AFAICT it requires emitting something much more compilcated (and possibly real code) instead of just some random bytes.

Reviewers: skatkov, sanjoy

Reviewed By: skatkov, sanjoy

Subscribers: sanjoy, aemerson, llvm-commits, kristof.beyls

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

llvm-svn: 315990

Change-Id: I60cd7e03ea6c3d9a3dc661a882458e83feca66e3
llvm-svn: 315985

llvm-svn: 315983

Updated the scheduling information for the SkylakeClient target with the following changes:

1. regrouped the instructions after adding load and store latencies.
2. regrouped the instructions after adding identified missing ports in several groups.
The changes were made after revisiting the latencies impact of all the load and store uOps.

Reviewers: zvi, RKSimon, craig.topper
Differential Revision: https://reviews.llvm.org/D38727

Change-Id: I778a308cc11e490e8fa5e27e2047412a1dca029f
llvm-svn: 315978

llvm-svn: 315977

llvm-svn: 315976

This patch reverts rL315440 because of the bug described at
https://bugs.llvm.org/show_bug.cgi?id=34937

The fix for the bug is on review as D38944, but not yet ready.  Given this is a regression reverting until a fix is ready is called for.

Max would have done the revert himself, but is having trouble doing a build of fresh LLVM for some reason.  I did the build and test to ensure the revert worked as expected on his behalf.

llvm-svn: 315974

llvm-svn: 315972

llvm-svn: 315971