Summary:
Move version control macros, find_first_existing_file and
find_first_existing_vc_file to AddLLVM.cmake so they can be reused by sub projects
like clang.

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

llvm-svn: 312419

We had these locals:
Value *Op0RHS = LHS->getOperand(1);
Value *Op1LHS = RHS->getOperand(0);
...so we confusingly transposed the meaning of left/right and op0/op1.

llvm-svn: 312418

LLVM transforms this into a bit test which is a lot faster and smaller.

llvm-svn: 312417

llvm-svn: 312416

This makes it easier to see that they're almost duplicates.
As with the similar icmp functions, there should be identical 
folds for both logic ops because those are DeMorganized variants.

llvm-svn: 312415

llvm-svn: 312414

llvm-svn: 312413

llvm-svn: 312412

These are all tests that result in a constant, so moving the tests over to where they are actually handled.

llvm-svn: 312411

In case a PHI node follows an error block we can assume that the incoming value
can only come from the node that is not an error block. As a result, conditions
that seemed non-affine before are now in fact affine.

llvm-svn: 312410

The binutils utility dwp has an option "-e" 
https://gcc.gnu.org/wiki/DebugFissionDWP
to specify an executable/library to get the list 
of *.dwo files from it. This option is particularly useful when 
someone runs the tool manually outside of a build system.
This diff adds an implementation of "-e" to llvm-dwp.

Test plan: make check-all

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

llvm-svn: 312409

COFF/DriverUtils.cpp uses buffer after WindowsManifestMerger destroyed.

llvm-svn: 312408

llvm-svn: 312407

Summary:
xmlDoc needs to be released with xmlFreeDoc.
XML_PARSE_NODICT is needed for safe moving nodes between documents.
Buffer returned from xmlDocDumpFormatMemoryEnc needs xmlFree, but it needs
outlive users of getMergedManifest results.

Reviewers: ecbeckmann, rnk, zturner, ruiu

Subscribers: llvm-commits

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

llvm-svn: 312406

We need to use target specific name for all runtimes targets. Target
specific name means the name of target in the LLVM build is different
from the name in runtimes build (in LLVM build, it's suffixed by the
target itself). Previously we have only used target specific names for
check targets collected through SUB_CHECK_TARGETS, but that's not
sufficient, we need to use target specific names for all targets we're
exposing in LLVM build.

Fixes PR34335.

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

llvm-svn: 312405

This was added in CL 1.1

Tested with a Radeon HD 7850 (Pitcairn) using the CL CTS via:
test_conformance/relationals/test_relationals shuffle_built_in_dual_input

v2: Add half support to shuffle2
    Move shuffle2 to misc/

Signed-off-by: Aaron Watry <awatry@gmail.com>
Reviewed-by: Jan Vesely <jan.vesely@rutgers.edu>
llvm-svn: 312404

This was added in CL 1.1

Tested with a Radeon HD 7850 (Pitcairn) using the CL CTS via:
test_conformance/relationals/test_relationals shuffle_built_in

v2: Add half-precision support to shuffle when available.
    Move to misc/ and add section 6.12.12 to clc.h

Signed-off-by: Aaron Watry <awatry@gmail.com>
Reviewed-by: Jan Vesely <jan.vesely@rutgers.edu>
llvm-svn: 312403

Uses the same mechanism to enable fp16 as we use for fp64 when
processing clc.h

Signed-off-by: Aaron Watry <awatry@gmail.com>
Reviewed-by: Jan Vesely <jan.vesely@rutgers.edu>
llvm-svn: 312402

Summary:
After a discussion with Rekka, i believe this (or a small variant)
should fix the remaining phi-of-ops problems.

Rekka's algorithm for completeness relies on looking up expressions
that should have no leader, and expecting it to fail (IE looking up
expressions that can't exist in a predecessor, and expecting it to
find nothing).

Unfortunately, sometimes these expressions can be simplified to
constants, but we need the lookup to fail anyway.  Additionally, our
simplifier outsmarts this by taking these "not quite right"
expressions, and simplifying them into other expressions or walking
through phis, etc.  In the past, we've sometimes been able to find
leaders for these expressions, incorrectly.

This change causes us to not to try to phi of ops such expressions.
We determine safety by seeing if they depend on a phi node in our
block.

This is not perfect, we can do a bit better, but this should be a
"correctness start" that we can then improve.  It also requires a
bunch of caching that i'll eventually like to eliminate.

The right solution, longer term, to the simplifier issues, is to make
the query interface for the instruction simplifier/constant folder
have the flags we need, so that we can keep most things going, but
turn off the possibly-invalid parts (threading through phis, etc).
This is an issue in another wrong code bug as well.

Reviewers: davide, mcrosier

Subscribers: sanjoy, llvm-commits

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

llvm-svn: 312401

llvm-svn: 312396

llvm-svn: 312395

llvm-svn: 312394

llvm-svn: 312393

Extract the handling of the `-fbuiltin` family of flags to the driver.
This centralises the handling of those options, keeping the long
standing `#if 0`'ed block of code.  This requires some additional code
archaeology to determine if we need to enable this functionality.

llvm-svn: 312392

Apply the simplification suggestions that Peter Collingbourne made
during the review at D37368.  The returned thunk is cast to the
appropriate type in the SymbolTable, and the constant symbol's body is
not needed directly, so avoid the assignment.  NFC

llvm-svn: 312391

Fix the Darwin logic so that -msse3 is only used on macOS, and
-fomit-frame-pointer is not used on armv7/armv7k/armv7s.

llvm-svn: 312390

This is needed for building LLVM on Android with new NDK (newer
than r15c) and API level < 24. Android C library (Bionic) didn't have
support for 64 bit file position until Android N.

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

llvm-svn: 312389

Testcase for rL312364:
[AMDGPU] Prevent infinite recursion in DAG.computeKnownBits()

llvm-svn: 312388

If getHexUint reads in a hex 0, it will create an APInt with a value of 0.
The number of active bits on this APInt is used to calculate the bitwidth of
Result. The number of active bits is defined as an APInt's bitwidth - its
number of leading 0s. Since this APInt is 0, its bitwidth and number of leading
0s are equal.

Thus, Result is constructed with a bitwidth of 0, triggering an APInt assert.

This commit fixes that by checking if the APInt is equal to 0, and setting the
bitwidth to 32 if it is. Otherwise, it sets the bitwidth using getActiveBits.

This caused issues when compiling MIR files with successor probabilities. In
the case that a successor is tagged with a probability of 0, this assert would
fire on debug builds.

https://reviews.llvm.org/D37401

llvm-svn: 312387

If a symbol is locally defined and is DLL imported in another
translation unit, and the object with the locally defined version is
loaded prior to the imported version, then the linker will fail to
resolve the definition of the thunk and return the locally defined
symbol.  This will then be attempted to be cast to an import thunk,
which will clearly fail.

Only return the thunk if the symbol is inserted or a thunk is created.
Otherwise, report a duplication error.

llvm-svn: 312386

Extract the logic for the floating point handling into its own function.
None of this information is needed for calculating the remainder of the
arguments to the frontend.  NFC

llvm-svn: 312385

Having p_filesz different from p_memsz is confusing some tools.

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

llvm-svn: 312384

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

llvm-svn: 312383

This patch teaches decomposeBitTestICmp to look through truncate instructions on the input to the compare. If a truncate is found it will now return the pre-truncated Value and appropriately extend the APInt mask.

This allows some code to be removed from InstSimplify that was doing this functionality.

This allows InstCombine's bit test combining code to match a pre-truncate Value with the same Value appear with an 'and' on another icmp. Or it allows us to combine a truncate to i16 and a truncate to i8. This also required removing the type check from the beginning of getMaskedTypeForICmpPair, but I believe that's ok because we still have to find two values from the input to each icmp that are equal before we'll do any transformation. So the type check was really just serving as an early out.

There was one user of decomposeBitTestICmp that didn't want to look through truncates, so I've added a flag to prevent that behavior when necessary.

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

llvm-svn: 312382

A future patch will make the code look through truncates feeding the compare. So the compares might be different types but the pretruncated types might be the same.

This should be safe because we still require the same Value* to be used truncated or not in both compares. So that serves to ensure the types are the same.

llvm-svn: 312381

[InstCombine] When converting decomposeBitTestICmp's APInt return to ConstantInt, make sure we use the type from the Value* that was also returned from decomposeBitTestICmp.

Previously we used the type from the LHS of the compare, but a future patch will change decomposeBitTestICmp to look through truncates so it will return a pretruncated Value* and the type needs to match that.

llvm-svn: 312380

This is limited to a set of patterns based on the example in PR34111:
https://bugs.llvm.org/show_bug.cgi?id=34111
...but as I was investigating this, I see that horizontal patterns can go wrong in many, 
many other ways that would not be handled by this patch. Each data type may even go 
different in the DAG after starting with the same basic IR pattern, so even proper IR 
canonicalization won't fix it all.

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

llvm-svn: 312379

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

llvm-svn: 312364

llvm-svn: 312361

llvm-svn: 312359