Const-correctness in libLTO

Looks like I was sloppy when bridging to C.
Thanks D. Blaikie for noticing!

From: Mehdi Amini <mehdi.amini@apple.com>

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@263885 91177308-0d34-0410-b5e6-96231b3b80d8

CodeGen: use range based for loop

Convert a loop to use a range based style loop.  NFC.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@263884 91177308-0d34-0410-b5e6-96231b3b80d8

[SimplifyLibCalls] Only consider sinpi/cospi functions within the same function

The sinpi/cospi can be replaced with sincospi to remove unnecessary
computations.  However, we need to make sure that the calls are within
the same function!

This fixes PR26993.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@263875 91177308-0d34-0410-b5e6-96231b3b80d8

[InstCombine] Don't insert instructions before a catch switch

CatchSwitches are not splittable, we cannot insert casts, etc. before
them.

This fixes PR26992.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@263874 91177308-0d34-0410-b5e6-96231b3b80d8

Add a dependency from llvm-link to TransformUtils following r263860

From: Mehdi Amini <mehdi.amini@apple.com>

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@263873 91177308-0d34-0410-b5e6-96231b3b80d8

[gold] Use early return to simplify.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@263872 91177308-0d34-0410-b5e6-96231b3b80d8

Removed trailing whitespace

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@263871 91177308-0d34-0410-b5e6-96231b3b80d8

Fix a const_cast related warning in GCC in the C API for libLTO

From: Mehdi Amini <mehdi.amini@apple.com>

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@263870 91177308-0d34-0410-b5e6-96231b3b80d8

Add a comment on partial hashing of Metadata

Following r263866, on D. Blaikie suggestion.

From: Mehdi Amini <mehdi.amini@apple.com>

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@263869 91177308-0d34-0410-b5e6-96231b3b80d8

[libFuzzer] one more trophie

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@263868 91177308-0d34-0410-b5e6-96231b3b80d8

Hash Metadata using pointer for MDString argument instead of value (NFC)

MDString are uniqued in the Context on creation, hashing the
pointer is less expensive than hashing the String itself.

Reviewers: dexonsmith
Differential Revision: http://reviews.llvm.org/D16560

From: Mehdi Amini <mehdi.amini@apple.com>

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@263867 91177308-0d34-0410-b5e6-96231b3b80d8

Compute some Debug Info Metadata hash key partially (NFC)

Summary:
This patch changes the computation of the hash key for DISubprogram to
be computed on a small subset of the fields. The hash is computed a
lot faster, but there might be more collision in the table.
However by carefully selecting the fields, colisions should be rare.

Using `opt` to load the IR for FastISelEmitter.cpp.o, with this patch:
 - DISubprogram::getImpl() goes from 28ms to 15ms.
 - DICompositeType::getImpl() goes from 6ms to 2ms
 - DIDerivedType::getImpl() goes from 18 to 12ms

Reviewers: dexonsmith

Subscribers: llvm-commits

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

From: Mehdi Amini <mehdi.amini@apple.com>

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@263866 91177308-0d34-0410-b5e6-96231b3b80d8

Rework linkInModule(), making it oblivious to ThinLTO

Summary:
ThinLTO is relying on linkInModule to import selected function.
However a lot of "magic" was hidden in linkInModule and the IRMover,
who would rename and promote global variables on the fly.

This is moving to an approach where the steps are decoupled and the
client is reponsible to specify the list of globals to import.
As a consequence some test are changed because they were relying on
the previous behavior which was importing the definition of *every*
single global without control on the client side.
Now the burden is on the client to decide if a global has to be imported
or not.

Reviewers: tejohnson

Subscribers: joker.eph, llvm-commits

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

From: Mehdi Amini <mehdi.amini@apple.com>

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@263863 91177308-0d34-0410-b5e6-96231b3b80d8

Add a test for r263577: "Add missing error handling in llvm-lto"

On Rafael's suggestion!
(also fix a discrepancy between this error message format and the others)

From: Mehdi Amini <mehdi.amini@apple.com>

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@263860 91177308-0d34-0410-b5e6-96231b3b80d8

[CXX_FAST_TLS] Fix issues in ARM.

We need to be careful on which registers can be explicitly handled
via copies. Prologue, Epilogue use physical registers and if one belongs
to the set of CSRsViaCopy, it will no longer be CSRed, since PEI overwrites
it after the explicit copies.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@263857 91177308-0d34-0410-b5e6-96231b3b80d8

[CXX_FAST_TLS] Disable tail call when calling conventions are mismatched.

Since CXX_FAST_TLS has a bigger set of CSRs, we don't tail call when caller
and callee have mismatched calling conventions.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@263856 91177308-0d34-0410-b5e6-96231b3b80d8

[CXX_FAST_TLS] fix issues with O0 on ARM, AArch64 and X86.

Since at O0, explicit copies via SplitCSR may not be removed even if
they are unnecessary, we choose not to use SplitCSR at O0.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@263855 91177308-0d34-0410-b5e6-96231b3b80d8

AArch64: Don't modify other modules in AArch64PromoteConstant

Avoid modifying other modules in `AArch64PromoteConstant` when the
constant is `ConstantData` (a horrible accident, I'm sure, caught by an
experimental follow-up to r261464).

Previously, this walked through all the users of a constant, but that
reaches into other modules when the constant doesn't depend transitively
on a `GlobalValue`!  Since we're walking instructions anyway, just
modify the instructions we actually see.

As a drive-by, instead of storing `Use` and getting the instructions
again via `Use::getUser()` (which is not a constantant time lookup),
store `std::pair<Instruction, unsigned>`.  Besides being cheaper, this
makes it easier to drop use-lists form `ConstantData` in the future.
(I threw this in because I was touching all the code anyway.)

Because the patch completely changes the traversal logic, it looks
like a rewrite of the pass, but the core logic is all the same (or
should be, minus the out-of-module changes).  In other words, there
should be NFC as long as the LLVMContext only has a single Module.

I didn't think of a good way to test this, but I hope to submit a patch
eventually that makes walking these use-lists illegal/impossible.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@263853 91177308-0d34-0410-b5e6-96231b3b80d8

[sancov] clang-formatting SanitizerCoverage.cpp and fully pleasing clang-tidy.

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

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@263852 91177308-0d34-0410-b5e6-96231b3b80d8

Have DataLayout::isLegalInteger() accept uint64_t

While not strictly necessary, since we don't support large integer
types, this avoids bugs due to silent truncation from uint64_t to a
32-bit unsigned (e.g. DL.isLegalInteger(DL.getTypeSizeInBits(Ty) )

This fixes PR26972.

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

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@263850 91177308-0d34-0410-b5e6-96231b3b80d8

[sancov] typo fix

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@263849 91177308-0d34-0410-b5e6-96231b3b80d8

[Support] Update comment to match actual behavior.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@263848 91177308-0d34-0410-b5e6-96231b3b80d8

Revert "Revert "[sancov] specifying sanitizer coverage dependencies.""

This reverts commit r263825, re-instating r263797.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@263847 91177308-0d34-0410-b5e6-96231b3b80d8

[sancov] reformat & 1 clang-tidy warning.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@263846 91177308-0d34-0410-b5e6-96231b3b80d8

[sancov] Fix the sancov pass to initialize itself inside its
constructor. This should fix the recent crashes on certain
architectures.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@263845 91177308-0d34-0410-b5e6-96231b3b80d8

Fixing autocorrect changing cmake->make

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@263843 91177308-0d34-0410-b5e6-96231b3b80d8

BPF: emit an error message for unsupported signed division operation

Signed-off-by: Yonghong Song <yhs@plumgrid.com>
Signed-off-by: Alexei Starovoitov <ast@fb.com>
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@263842 91177308-0d34-0410-b5e6-96231b3b80d8

Missed a few non-ascii characters

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@263841 91177308-0d34-0410-b5e6-96231b3b80d8

Updates based on post-commit review of r263834

* Renamed to be camel case, consistent with other docs.
* Fixed non-ascii characters (this is what I get for writing docs on an iPad).

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@263840 91177308-0d34-0410-b5e6-96231b3b80d8

[obj2yaml, COFF] Assert that the alignment is not bogus

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@263839 91177308-0d34-0410-b5e6-96231b3b80d8

Interface to get/set profile summary metadata to module

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

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@263835 91177308-0d34-0410-b5e6-96231b3b80d8

[Docs] New documentation for advanced build configurations

This document covers how to use some of the new complex build configurations CMake supports.

Feedback and improvements welcomed!

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@263834 91177308-0d34-0410-b5e6-96231b3b80d8

[libFuzzer] add a flag close_fd_mask so that we can silence spammy targets by closing stderr/stdout

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@263831 91177308-0d34-0410-b5e6-96231b3b80d8

MILexer: Add ErrorCallbackType typedef; NFC

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@263829 91177308-0d34-0410-b5e6-96231b3b80d8

[IndVars] Make the fix for PR26973 more obvious; NFCI

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@263828 91177308-0d34-0410-b5e6-96231b3b80d8

[IndVars] Pass the right loop to isLoopInvariantPredicate

The loop on IVOperand's incoming values assumes IVOperand to be an
induction variable on the loop over which `S Pred X` is invariant;
otherwise loop invariant incoming values to IVOperand are not guaranteed
to dominate the comparision.

This fixes PR26973.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@263827 91177308-0d34-0410-b5e6-96231b3b80d8

Revert "[sancov] specifying sanitizer coverage dependencies."

This fails on arm.

This reverts commit 52c8e0f7119d1ea1050c0708565a8c92b73386d2.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@263825 91177308-0d34-0410-b5e6-96231b3b80d8

AMDGPU: add missing braces around multi-line if block

This fixes an issue with rL263658 pointed out by Tom Stellard.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@263823 91177308-0d34-0410-b5e6-96231b3b80d8

Typesafe visualization of PointerIntPairs in Visual Studio

In the <DisplayString> of PointerIntPair , I cast the pointer to the actual type, so VS can leverage it while visualizing, not unlike the recent change to PointerUnion visualization.
In the expansion, the current code is casting to the incorrect type (wrong number of stars), so I fixed that as well.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@263821 91177308-0d34-0410-b5e6-96231b3b80d8

[AArch64] Enable more load clustering in the MI Scheduler.

This patch adds unscaled loads and sign-extend loads to the TII
getMemOpBaseRegImmOfs API, which is used to control clustering in the MI
scheduler. This is done to create more opportunities for load pairing.  I've
also added the scaled LDRSWui instruction, which was missing from the scaled
instructions. Finally, I've added support in shouldClusterLoads for clustering
adjacent sext and zext loads that too can be paired by the load/store optimizer.

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

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@263819 91177308-0d34-0410-b5e6-96231b3b80d8

[codeview] Only emit function ids for inlined functions

We aren't referencing any other kind of function currently.
Should save a bit on our debug info size.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@263817 91177308-0d34-0410-b5e6-96231b3b80d8

[MCParser] Accept uppercase radix variants 0X and 0B

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

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@263802 91177308-0d34-0410-b5e6-96231b3b80d8

[sancov] specifying sanitizer coverage dependencies.

Summary:
These dependencies would be used in the future to reduce the number
of instrumented blocks(http://reviews.llvm.org/rL262103)

This is submitted as a separate CL because of previous problems with
ARM.

Subscribers: aemerson

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

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@263797 91177308-0d34-0410-b5e6-96231b3b80d8

[llvm-objdump] Print <unknown> in place of instruction text if it couldn't be disassembled.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@263793 91177308-0d34-0410-b5e6-96231b3b80d8

AMDGPU: Overload return type of llvm.amdgcn.buffer.load.format

Summary:
Allow the selection of BUFFER_LOAD_FORMAT_x and _XY. Do this now before
the frontend patches land in Mesa. Eventually, we may want to automatically
reduce the size of loads at the LLVM IR level, which requires such overloads,
and in some cases Mesa can generate them directly.

Reviewers: tstellarAMD, arsenm

Subscribers: arsenm, llvm-commits

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

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@263792 91177308-0d34-0410-b5e6-96231b3b80d8

AMDGPU/SI: Add llvm.amdgcn.buffer.atomic.* intrinsics

Summary:
These intrinsics expose the BUFFER_ATOMIC_* instructions and will be used
by Mesa to implement atomics with buffer semantics. The intrinsic interface
matches that of buffer.load.format and buffer.store.format, except that the
GLC bit is not exposed (it is automatically deduced based on whether the
return value is used).

The change of hasSideEffects is required for TableGen to accept the pattern
that matches the intrinsic.

Reviewers: tstellarAMD, arsenm

Subscribers: arsenm, rivanvx, llvm-commits

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

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@263791 91177308-0d34-0410-b5e6-96231b3b80d8

AMDGPU: use ComplexPattern for offsets in llvm.amdgcn.buffer.load/store.format

Summary:
We cannot easily deduce that an offset is in an SGPR, but the Mesa frontend
cannot easily make use of an explicit soffset parameter either. Furthermore,
it is likely that in the future, LLVM will be in a better position than the
frontend to choose an SGPR offset if possible.

Since there aren't any frontend uses of these intrinsics in upstream
repositories yet, I would like to take this opportunity to change the
intrinsic signatures to a single offset parameter, which is then selected
to immediate offsets or voffsets using a ComplexPattern.

Reviewers: arsenm, tstellarAMD, mareko

Subscribers: arsenm, llvm-commits

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

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@263790 91177308-0d34-0410-b5e6-96231b3b80d8

[AMDGPU] Assembler: Change dpp_ctrl syntax to match sp3

Review: http://reviews.llvm.org/D18267

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@263789 91177308-0d34-0410-b5e6-96231b3b80d8

[Fuzzer] Guard no_sanitize_memory attributes behind __has_feature.

Otherwise GCC fails to build it because it doesn't know the attribute.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@263787 91177308-0d34-0410-b5e6-96231b3b80d8

Fix some typos; NFC

Patch by Dongyuan Liu.

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

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@263786 91177308-0d34-0410-b5e6-96231b3b80d8

[llvm-objdump] Move test case to the X86 sub-directory because it depends on X86 target supporting. NFC.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@263781 91177308-0d34-0410-b5e6-96231b3b80d8

Always cache resolved paths as it even saves on StringMap lookups.

Now that the resolved path cache stores the StringRef's, its
best to just always cache the results, even when realpath isn't
used.  This way we'll still avoid the StringMap hashing and lookup.

This also conveniently reorganises this code in a way I need for
a future patch.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@263777 91177308-0d34-0410-b5e6-96231b3b80d8

adding another optimization opportunity to readme file

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@263775 91177308-0d34-0410-b5e6-96231b3b80d8

Use StringRef's in resolved path cache to avoid extra internString lookups.  NFC.

ResolvedPaths was storing std::string's as a cache. We would then take those strings and look them up in the internString pool to get a unique StringRef for each path.

This patch changes ResolvedPaths to store the StringRef pointing in to the internString pool itself. This way, when getResolvedPath returns a string, we know we have the StringRef we would find in the pool anyway. We can avoid the duplicate memory of the std::string's, and also the time from the lookup.

Unfortunately my profiles show no runtime change here, but it should still save memory allocations which is nice.

Reviewed by Frederic Riss.

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

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@263774 91177308-0d34-0410-b5e6-96231b3b80d8

[libFuzzer] read corpus dirs recursively

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@263773 91177308-0d34-0410-b5e6-96231b3b80d8

[LoopDataPrefetch] Add TTI to limit the number of iterations to prefetch ahead

Summary:
It can hurt performance to prefetch ahead too much.  Be conservative for
now and don't prefetch ahead more than 3 iterations on Cyclone.

Reviewers: hfinkel

Subscribers: llvm-commits, mzolotukhin

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

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@263772 91177308-0d34-0410-b5e6-96231b3b80d8

[LoopDataPrefetch/Aarch64] Allow selective prefetching of large-strided accesses

Summary:
And use this TTI for Cyclone.  As it was explained in the original RFC
(http://thread.gmane.org/gmane.comp.compilers.llvm.devel/92758), the HW
prefetcher work up to 2KB strides.

I am also adding tests for this and the previous change (D17943):

* Cyclone prefetching accesses with a large stride
* Cyclone not prefetching accesses with a small stride
* Generic Aarch64 subtarget not prefetching either

Reviewers: hfinkel

Subscribers: aemerson, rengolin, llvm-commits, mzolotukhin

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

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@263771 91177308-0d34-0410-b5e6-96231b3b80d8

[Aarch64] Add pass LoopDataPrefetch for Cyclone

Summary:
This wires up the pass for Cyclone but keeps it off for now because we
need a few more TTIs.

The getPrefetchMinStride value is not very well tuned right now but it
works well with CFP2006/433.milc which motivated this.

Tests will be added as part of the upcoming large-stride prefetching
patch.

Reviewers: t.p.northover

Subscribers: llvm-commits, aemerson, hfinkel, rengolin

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

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@263770 91177308-0d34-0410-b5e6-96231b3b80d8

[libFuzzer] improve -merge functionality

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@263769 91177308-0d34-0410-b5e6-96231b3b80d8

[Support] Refactor Error unit tests to avoid duplicating work.

Suggested by Dave Blaikie in review for r263749. Thanks Dave!

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@263768 91177308-0d34-0410-b5e6-96231b3b80d8

[sancov] html report: replacing uncovered functions with function coverage % table.

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

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@263767 91177308-0d34-0410-b5e6-96231b3b80d8

DebugInfo: Add ability to not emit DW_AT_vtable_elem_location for virtual functions.

A virtual index of -1u indicates that the subprogram's virtual index is
unrepresentable (for example, when using the relative vtable ABI), so do
not emit a DW_AT_vtable_elem_location attribute for it.

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

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@263765 91177308-0d34-0410-b5e6-96231b3b80d8

[Support] Address some of dblaikie's feedback for r263749.

Fixes some missing std::moves and take Expected<T> by rvalue reference in the
call operator.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@263764 91177308-0d34-0410-b5e6-96231b3b80d8

Revert "allow lambdas in mapped_iterator"

MSVC as usual:

C:\Buildbot\Slave\llvm-clang-lld-x86_64-scei-ps4-windows10pro-fast\llvm.src\include\llvm/ADT/STLExtras.h(120):
error C2100: illegal indirection
C:\Buildbot\Slave\llvm-clang-lld-x86_64-scei-ps4-windows10pro-fast\llvm.src\include\llvm/IR/Instructions.h(3966):
note: see reference to class template instantiation
'llvm::mapped_iterator<llvm::User::op_iterator,llvm::CatchSwitchInst::DerefFnTy>'
being compiled

This reverts commit e091dd63f1f34e043748e28ad160d3bc17731168.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@263760 91177308-0d34-0410-b5e6-96231b3b80d8

allow lambdas in mapped_iterator

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

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@263759 91177308-0d34-0410-b5e6-96231b3b80d8

[Docs] Fix a typo.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@263754 91177308-0d34-0410-b5e6-96231b3b80d8

[PPC, FastISel] Fix ordered/unordered fcmp

For fcmp, major concern about the following 6 cases is NaN result. The
comparison result consists of 4 bits, indicating lt, eq, gt and un (unordered),
only one of which will be set. The result is generated by fcmpu
instruction. However, bc instruction only inspects one of the first 3
bits, so when un is set, bc instruction may jump to to an undesired
place.

More specifically, if we expect an unordered comparison and un is set, we
expect to always go to true branch; in such case UEQ, UGT and ULT still
give false, which are undesired; but UNE, UGE, ULE happen to give true,
since they are tested by inspecting !eq, !lt, !gt, respectively.

Similarly, for ordered comparison, when un is set, we always expect the
result to be false. In such case OGT, OLT and OEQ is good, since they are
actually testing GT, LT, and EQ respectively, which are false. OGE, OLE
and ONE are tested through !lt, !gt and !eq, and these are true.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@263753 91177308-0d34-0410-b5e6-96231b3b80d8

[Support] Add ExitOnError utility to support tools that use the exit-on-error
idiom.

Most LLVM tool code exits immediately when an error is encountered and prints an
error message to stderr. The ExitOnError class supports this by providing two
call operators - one for Errors, and one for Expected<T>s. Calls to code that
can return Errors (or Expected<T>s) can use these calls to bail out on error,
and otherwise continue as if the operation had succeeded. E.g.

Error foo();
Expected<int> bar();

int main(int argc, char *argv[]) {
  ExitOnError ExitOnErr;

  ExitOnErr.setBanner(std::string("Error in ") + argv[0] + ":");

  // Exit if foo returns an error. No need to manually check error return.
  ExitOnErr(foo());

  // Exit if bar returns an error, otherwise unwrap the contained int and
  // continue.
  int X = ExitOnErr(bar());

  // ...

  return 0;
}

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@263749 91177308-0d34-0410-b5e6-96231b3b80d8

[Support] Make Error::isA<T>() works on success values.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@263745 91177308-0d34-0410-b5e6-96231b3b80d8

[LoopVectorize] Annotate versioned loop with noalias metadata

Summary:
Use the new LoopVersioning facility (D16712) to add noalias metadata in
the vector loop if we versioned with memchecks.  This can enable some
optimization opportunities further down the pipeline (see the included
test or the benchmark improvement quoted in D16712).

The test also covers the bug I had in the initial version in D16712.

The vectorizer did not previously use LoopVersioning.  The reason is
that the vectorizer performs its transformations in single shot.  It
creates an empty single-block vector loop that it then populates with
the widened, if-converted instructions.  Thus creating an intermediate
versioned scalar loop seems wasteful.

So this patch (rather than bringing in LoopVersioning fully) adds a
special interface to LoopVersioning to allow the vectorizer to add
no-alias annotation while still performing its own versioning.

As the vectorizer propagates metadata from the instructions in the
original loop to the vector instructions we also check the pointer in
the original instruction and see if LoopVersioning can add no-alias
metadata based on the issued memchecks.

Reviewers: hfinkel, nadav, mzolotukhin

Subscribers: mzolotukhin, llvm-commits

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

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@263744 91177308-0d34-0410-b5e6-96231b3b80d8

[LoopVersioning] Annotate versioned loop with noalias metadata

Summary:
If we decide to version a loop to benefit a transformation, it makes
sense to record the now non-aliasing accesses in the newly versioned
loop.  This allows non-aliasing information to be used by subsequent
passes.

One example is 456.hmmer in SPECint2006 where after loop distribution,
we vectorize one of the newly distributed loops.  To vectorize we
version this loop to fully disambiguate may-aliasing accesses.  If we
add the noalias markers, we can use the same information in a later DSE
pass to eliminate some dead stores which amounts to ~25% of the
instructions of this hot memory-pipeline-bound loop.  The overall
performance improves by 18% on our ARM64.

The scoped noalias annotation is added in LoopVersioning.  The patch
then enables this for loop distribution.  A follow-on patch will enable
it for the vectorizer.  Eventually this should be run by default when
versioning the loop but first I'd like to get some feedback whether my
understanding and application of scoped noalias metadata is correct.

Essentially my approach was to have a separate alias domain for each
versioning of the loop.  For example, if we first version in loop
distribution and then in vectorization of the distributed loops, we have
a different set of memchecks for each versioning.  By keeping the scopes
in different domains they can conveniently be defined independently
since different alias domains don't affect each other.

As written, I also have a separate domain for each loop.  This is not
necessary and we could save some metadata here by using the same domain
across the different loops.  I don't think it's a big deal either way.

Probably the best is to review the tests first to see if I mapped this
problem correctly to scoped noalias markers.  I have plenty of comments
in the tests.

Note that the interface is prepared for the vectorizer which needs the
annotateInstWithNoAlias API.  The vectorizer does not use LoopVersioning
so we need a way to pass in the versioned instructions.  This is also
why the maps have to become part of the object state.

Also currently, we only have an AA-aware DSE after the vectorizer if we
also run the LTO pipeline.  Depending how widely this triggers we may
want to schedule a DSE toward the end of the regular pass pipeline.

Reviewers: hfinkel, nadav, ashutosh.nema

Subscribers: mssimpso, aemerson, llvm-commits, mcrosier

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

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@263743 91177308-0d34-0410-b5e6-96231b3b80d8

Bitcode: Error out instead of crashing on corrupt metadata

I hit a crash in the bitcode reader on some corrupt input where an
MDString had somehow been attached to an instruction instead of an
MDNode. This input is pretty bogus, but we shouldn't be crashing on bad
input here.

This change adds error handling in all of the places where we
currently have unchecked casts from Metadata to MDNode, which means
we'll error out instead of crashing for that sort of input.

Unfortunately, I don't have tests. Hitting this requires flipping bits
in the input bitcode, and committing corrupt binary files to catch
these cases is a bit too opaque and unmaintainable.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@263742 91177308-0d34-0410-b5e6-96231b3b80d8

ARM: stop asserting on weird <3 x Ty> vectors in ISelLowering.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@263741 91177308-0d34-0410-b5e6-96231b3b80d8

[libFuzzer] deprecate several flags

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@263739 91177308-0d34-0410-b5e6-96231b3b80d8

[libFuzzer] add __attribute__((no_sanitize_memory)) to two functions that may be called from signal handler(s) or from msan. This will hopefully avoid msan false reports which I can't reproduce

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@263737 91177308-0d34-0410-b5e6-96231b3b80d8

[msan fix] unitalized variable

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@263736 91177308-0d34-0410-b5e6-96231b3b80d8

[InstCombine] Combine A->B->A BitCast

This patch enhances InstCombine to handle following case:

        A  ->  B    bitcast
        PHI
        B  ->  A    bitcast

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@263734 91177308-0d34-0410-b5e6-96231b3b80d8

[Statepoints] Export a magic constant into a header; NFC

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@263733 91177308-0d34-0410-b5e6-96231b3b80d8

[lit] Enqueue tests on a separate thread to not hit limits on parallel queues

Summary:
The multiprocessing.Queue.put() call can hang if we try queueing all the
tests before starting to take them out of the queue.
The current implementation hangs if tests exceed 2^^15, on Mac OS X.
This might happen with a ninja check-all if one has a bunch of llvm
projects.

Reviewers: delcypher, bkramer

Subscribers: llvm-commits

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

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@263731 91177308-0d34-0410-b5e6-96231b3b80d8

[AMDGPU] add VI disassembler tests. NFC.

Autogenerated from the corresponding assembler tests with a few FIXME added (will fix soon).

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

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@263729 91177308-0d34-0410-b5e6-96231b3b80d8

[PowerPC] Disable CTR loops optimization for soft float operations

This patch prevents CTR loops optimization when using soft float operations
inside loop body. Soft float operations use function calls, but function
calls are not allowed inside CTR optimized loops.

Patch by Aleksandar Beserminji.

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

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@263727 91177308-0d34-0410-b5e6-96231b3b80d8

[WebAssembly] Stackify code emitted by eliminateFrameIndex and SP writeback

Summary:
MRI::eliminateFrameIndex can emit several instructions to do address
calculations; these can usually be stackified. Because instructions with
FI operands can have subsequent operands which may be expression trees,
find the top of the leftmost tree and insert the code before it, to keep
the LIFO property.

Also use stackified registers when writing back the SP value to memory
in the epilog; it's unnecessary because SP will not be used after the
epilog, and it results in better code.

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

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@263725 91177308-0d34-0410-b5e6-96231b3b80d8

[COFF] Refactor section alignment calculation

Section alignment isn't completely trivial, let it live in one place so
that we may reuse it in LLVM.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@263722 91177308-0d34-0410-b5e6-96231b3b80d8

Forgot to commit this with r263692

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@263721 91177308-0d34-0410-b5e6-96231b3b80d8

AMDGPU/SI: Do not generate s_waitcnt after ds_permute/ds_bpermute

Symmary:
  ds_permute/ds_bpermute do not read memory so s_waitcnt is not needed.

Reviewers
  arsenm, tstellarAMD

Subscribers
  llvm-commits, arsenm

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

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@263720 91177308-0d34-0410-b5e6-96231b3b80d8

AMDGPU: mark atomic instructions as sources of divergence

Summary:
As explained by the comment, threads will typically see different values
returned by atomic instructions even if the arguments are equal.

Reviewers: arsenm, tstellarAMD

Subscribers: arsenm, llvm-commits

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

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@263719 91177308-0d34-0410-b5e6-96231b3b80d8

[X86][SSE] Simplified blend-with-zero combining

We were being too aggressive in trying to combine a shuffle into a blend-with-zero pattern, often resulting in a endless loop of contrasting combines

This patch stops the combine if we already have a blend in place (means we miss some domain corrections)

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@263717 91177308-0d34-0410-b5e6-96231b3b80d8

propagate 'unpredictable' metadata on select instructions

This is similar to D18133 where we allowed profile weights on select instructions.
This extends that change to also allow the 'unpredictable' attribute of branches to apply to selects.

A test to check that 'unpredictable' metadata is preserved when cloning instructions was checked in at:
http://reviews.llvm.org/rL263648

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

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@263716 91177308-0d34-0410-b5e6-96231b3b80d8

ARM: Revert SVN r253865, 254158, fix windows division

The two changes together weakened the test and caused a regression with division
handling in MSVC mode.  They were applied to avoid an assertion being triggered
in the block frequency analysis.  However, the underlying problem was simply
being masked rather than solved properly.  Address the actual underlying problem
and revert the changes.  Rather than analyze the cause of the assertion, the
division failure was assumed to be an overflow.

The underlying issue was a subtle bug in the BB construction in the emission of
the div-by-zero check (WIN__DBZCHK).  We did not construct the proper successor
information in the basic blocks, nor did we update the PHIs associated with the
basic block when we split them.  This would result in assertions being triggered
in the block frequency analysis pass.

Although the original tests are being removed, the tests themselves performed
very little in terms of validation but merely tested that we did not assert when
generating code.  Update this with new tests that actually ensure that we do not
regress on the code generation.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@263714 91177308-0d34-0410-b5e6-96231b3b80d8

[llvm-objdump] Add REQUIRES x86 directive to fix buildbots

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@263708 91177308-0d34-0410-b5e6-96231b3b80d8

[llvm-objdump] Add '0x' prefix to a target displacement number to accent its hex format

It might be hard to recognize a hexadecimal number without '0x' prefix.
Besides that '0x' prefix corresponds to GNU objdump behaviour.

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

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@263705 91177308-0d34-0410-b5e6-96231b3b80d8

[mips] Use `formatImm` call to print immediate value in the `MipsInstPrinter`

That allows, for example, to print hex-formatted immediates using
llvm-objdump --print-imm-hex command line option.

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

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@263704 91177308-0d34-0410-b5e6-96231b3b80d8

[mips] Eliminate instances of "potentially uninitialised local variable" warnings, NFC

Summary:
This should eliminate all occurrences of this within LLVMMipsAsmParser.
This patch is in response to http://reviews.llvm.org/D17983. I was unable
to reproduce the warnings on my machine so please advise if this fixes the
warnings.

Reviewers: ariccio, vkalintiris, dsanders

Subscribers: dblaikie, dsanders, llvm-commits

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

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@263703 91177308-0d34-0410-b5e6-96231b3b80d8

Remove obselete reference to TypeResolve from the tutorial.

TypeResolve went away in r134829 in 2011.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@263702 91177308-0d34-0410-b5e6-96231b3b80d8

Minor grammar fix in kaleidoscope tutorial.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@263700 91177308-0d34-0410-b5e6-96231b3b80d8

Further typo fixes in kaleidoscope tutorial.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@263697 91177308-0d34-0410-b5e6-96231b3b80d8

Fix typo in kaleidoscope tutorial.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@263696 91177308-0d34-0410-b5e6-96231b3b80d8

[yaml2obj, COFF] Correctly handle section alignment

The section alignment field was marked optional but not provided a
default value: initialize it with 0.

While we are here, ensure that the section alignment is plausible.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@263692 91177308-0d34-0410-b5e6-96231b3b80d8

[Statepoints] Separate out logic for statepoint directives; NFC

This splits out the logic that maps the `"statepoint-id"` attribute into
the actual statepoint ID, and the `"statepoint-num-patch-bytes"`
attribute into the number of patchable bytes the statpeoint is lowered
into.  The new home of this logic is in IR/Statepoint.cpp, and this
refactoring will support similar functionality when lowering calls with
deopt operand bundles in the future.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@263685 91177308-0d34-0410-b5e6-96231b3b80d8

[Statepoint] Remove unused header; NFC

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@263684 91177308-0d34-0410-b5e6-96231b3b80d8