LLVM_BUILD_GLOBAL_ISEL

llvm-svn: 260457

llvm-svn: 260456

Summary: Measured to be more performant when reading bitcode.

Reviewers: rafael, dexonsmith

Subscribers: llvm-commits

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

From: Mehdi Amini <mehdi.amini@apple.com>
llvm-svn: 260455

The Use argument was used to compute the operand number for a fast
path when replacing only one operand. However we always have to go
through all the operands. So the argument number can be recomputed
locally anyway.

From: Mehdi Amini <mehdi.amini@apple.com>
llvm-svn: 260454

It looks like clang has a couple of test cases which caught the fact LVI was not slightly more precise after 260439.  When looking at the failures, it struck me as wasteful to be querying nullness of a constant via LVI, so instead of tweaking the clang tests, let's just stop querying constants from this source.

llvm-svn: 260451

The patch adds a parameter in annotateValueSite() to control the max number
of records written to the value profile meta data for each value site. The
default is kept as the current value of 3.

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

llvm-svn: 260450

Previously the code used getActiveBits() to determine the highest set
bit of each APInt first. However doing so requires the same amount of
memory accesses as simply comparing both numbers right away.

Removing all the active bit checks leads to simpler code and is faster
in my benchmark.

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

llvm-svn: 260447

llvm-svn: 260446

This restores commit r260408, along with a fix for a bot failure.

The bot failure was caused by dereferencing a unique_ptr in the same
call instruction parameter list where it was passed via std::move.
Apparently due to luck this was not exposed when I built the compiler
with clang, only with gcc.

llvm-svn: 260442

There's nothing preventing callers of LVI from asking for lattice values representing a Constant.  In fact, given that several callers are walking back through PHI nodes and trying to simplify predicates, such queries are actually quite common.  This is mostly harmless today, but we start volatiling assertions if we add new calls to getBlockValue in otherwise reasonable places.

Note that this change is not NFC.  Specifically:
1) The result returned through getValueAt will now be more precise.  In principle, this could trigger any latent infinite optimization loops in callers, but in practice, we're unlikely to see this.
2) The result returned through getBlockValueAt is potentially weakened for non-constants that were previously queried.  With the old code, you had the possibility that a later query might bypass the cache and discover some information the original query did not.  I can't find a scenario which actually causes this to happen, but it was in principle possible.  On the other hand, this may end up reducing compile time when the same value is queried repeatedly.  

llvm-svn: 260439

llvm-svn: 260438

Summary:
Refactor common value, scope, and label tracking logic out of DwarfDebug
into a common base class called DebugHandlerBase.

Update an old LLVM IR test case to avoid an assertion in LexicalScopes.

Reviewers: dblaikie, majnemer

Subscribers: llvm-commits

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

llvm-svn: 260432

New option --elf-output-style=LLVM or GNU
Enables -file-headers in readelf style when elf-output-style=GNU

Differential revision: http://reviews.llvm.org/D14128

llvm-svn: 260430

llvm-svn: 260429

llvm-svn: 260428

Summary:
This fixes a crash where subsequent spills would be unable to scavenge
a register. In particular, it fixes a crash in piglit's
spec@glsl-1.50@execution@geometry@max-input-components (the test still
has a shader that fails to compile because of too many SGPR spills, but
at least it doesn't crash any more).

This is a candidate for the release branch.

Reviewers: arsenm, tstellarAMD

Subscribers: qcolombet, arsenm

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

llvm-svn: 260427

llvm-svn: 260426

Instead of passing varargs directly on the user stack, allocate a buffer in
the caller's stack frame and pass a pointer to it. This simplifies the C
ABI (e.g. non-C callers of C functions do not need to use C's user stack if
they have their own mechanism) and allows further optimizations in the future
(e.g. fewer functions may need to use the stack).

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

llvm-svn: 260421

llvm-svn: 260419

llvm-svn: 260418

Very often in LLVM we have APIs that take a bitwidth and a uint64_t that
we pass immediates such as ~0U to. Consider APInt, Constant, and
MachineInstrBuilder::addImm. Fixing all uses of these APIs to manually
extend their arguments to uint64_t doesn't seem worth it.

llvm-svn: 260416

llvm-svn: 260413

This reverts commit r260408. Bot failure that I need to investigate.

llvm-svn: 260412

Patch by Alexander Riccio

This patch enables `constexpr` on Visual Studio 2015 by adding `||
LLVM_MSC_PREREQ(1900)` to the preprocessor `#if` statement. Since VS2013
doesn't support `constexpr`, that's purposely excluded. The
`LLVM_CONSTEXPR` macro is used in ~25 places.

I also added the MSVC/SAL equivalent of:

  - `__attribute__((__warn_unused_result__))` as an
    `LLVM_ATTRIBUTE_UNUSED_RESULT` definition

  - `__attribute__((returns_nonnull))` as an
    `LLVM_ATTRIBUTE_RETURNS_NONNULL` definition

...in case anybody ever decides to run `/analyze` on LLVM (probably
myself, if anybody)

Reviewers: rnk, aaron.ballman

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

llvm-svn: 260410

llvm-svn: 260409

Summary:
This patch uses the lower 64-bits of the MD5 hash of a function name as
a GUID in the function index, instead of storing function names. Any
local functions are first given a global name by prepending the original
source file name. This is the same naming scheme and GUID used by PGO in
the indexed profile format.

This change has a couple of benefits. The primary benefit is size
reduction in the combined index file, for example 483.xalancbmk's
combined index file was reduced by around 70%. It should also result in
memory savings for the index file in memory, as the in-memory map is
also indexed by the hash instead of the string.

Second, this enables integration with indirect call promotion, since the
indirect call profile targets are recorded using the same global naming
convention and hash. This will enable the function importer to easily
locate function summaries for indirect call profile targets to enable
their import and subsequent promotion.

The original source file name is recorded in the bitcode in a new
module-level record for use in the ThinLTO backend pipeline.

Reviewers: davidxl, joker.eph

Subscribers: llvm-commits, joker.eph

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

llvm-svn: 260408

llvm-svn: 260407

llvm-svn: 260406

llvm-svn: 260405

Currently you can't specify node properties like commutativity on
a PatFrag. If you want to create a PatFrag on a commutative node
with a hasOneUse predicate, this enables you to specify that the
PatFrag is also commutable.

llvm-svn: 260404

llvm-svn: 260403

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

llvm-svn: 260401

This patch reads the indirect-call value records in the profile and makes the
annotation in the indirect-call instruction. This is for IR level profile
instrumentation.

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

llvm-svn: 260400

llvm-svn: 260399

These weren't actually sharing anything in the common
LowerLOAD.

llvm-svn: 260398

This reverts commit a58765909660a7195b32e0cc8c7476168b913750.

llvm-svn: 260397

llvm-svn: 260396

Summary:
As discussed on IRC, move the ThinLTOGlobalProcessing code out of
the linker, and into TransformUtils. The name of the class is changed
to FunctionImportGlobalProcessing.

Reviewers: joker.eph, rafael

Subscribers: joker.eph, llvm-commits

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

llvm-svn: 260395

Fix the result truncation bug: [PR26560]
Test case is following (compiler-rt).
 

llvm-svn: 260393

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

llvm-svn: 260392