llvm-svn: 257627

llvm-svn: 257626

Reviewers: tstellarAMD, arsenm

Subscribers: arsenm

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

llvm-svn: 257625

Reviewers: tstellarAMD, arsenm

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

llvm-svn: 257624

Reviewers: tstellarAMD, arsenm

Subscribers: arsenm

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

llvm-svn: 257623

Summary:
v2: Make ReturnsVoid private, so that I can another 8 lines of code and
    look more productive.

Reviewers: tstellarAMD, arsenm

Subscribers: arsenm

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

llvm-svn: 257622

Summary:
Return values can be stored in SGPRs (i32) and VGPRs (f32).

This will be used by functions which expect some bytecode or other binary to
be appended at the end. It allows defining in which registers the return
values will be stored.

v2: don't do this for compute shaders

Reviewers: tstellarAMD, arsenm

Subscribers: arsenm

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

llvm-svn: 257621

WebAssemblyCFGStackify does not track liveness for EXPR_STACK, causing
verifier failure if liveness has not already been invalidated.

llvm-svn: 257620

llvm-svn: 257617

is < ``2.0``.

Older versions of psutil (e.g. ``1.2.1`` which is the version shipped with
Ubuntu 14.04) use a different API for retrieving the child processes.
To handle this try the new API first and if that fails try the old API.

llvm-svn: 257616

llvm-svn: 257613

llvm-svn: 257611

Summary:
It is off by default, but can be used
with --misched=si

Patch by: Axel Davy

Reviewers: arsenm, tstellarAMD, nhaehnle

Subscribers: nhaehnle, solenskiner, arsenm, llvm-commits

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

llvm-svn: 257609

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

llvm-svn: 257607

llvm-svn: 257606

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

llvm-svn: 257604

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

llvm-svn: 257601

The global entry point prologue currently assumes that the TOC
associated with a function is less than 2GB away from the function
entry point.  This is always true when using the medium or small
code model, but may not be the case when using the large code model.

This patch adds a new variant of the ELFv2 global entry point prologue
that lifts the 2GB restriction when building with -mcmodel=large.
This works by emitting a quadword containing the distance from the
function entry point to its associated TOC immediately before the
entry point, and then using a prologue like:

ld r2,-8(r12)
add r2,r2,r12

Since creation of the entry point prologue is now split across two
separate routines (PPCLinuxAsmPrinter::EmitFunctionEntryLabel emits
the data word, PPCLinuxAsmPrinter::EmitFunctionBodyStart the prolog
code), I've switched to using named labels instead of just temporaries
to indicate the locations of the global and local entry points and the
new TOC offset data word.

These names are provided by new routines in PPCFunctionInfo modeled
after the existing PPCFunctionInfo::getPICOffsetSymbol.

Note that a corresponding change was committed to GCC here:
https://gcc.gnu.org/ml/gcc-patches/2015-12/msg00355.html

Reviewers: hfinkel

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

llvm-svn: 257597

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

llvm-svn: 257594

Reviewers: tstellarAMD, arsenm

Subscribers: arsenm

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

llvm-svn: 257593

Summary:
With the ability to concatenate shader binaries, the limit of 15 no longer
applies.

Reviewers: tstellarAMD, arsenm

Subscribers: arsenm

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

llvm-svn: 257592

Summary:
This allows Mesa to pass initial SPI_PS_INPUT_ADDR to LLVM.
The register assigns VGPR locations to PS inputs, while the ENA register
determines whether or not they are loaded.

Mesa needs to set some inputs as not-movable, so that a pixel shader prolog
binary appended at the beginning can assume where some inputs are.

v2: Make PSInputAddr private, because there is never enough silly getters
    and setters for people to read.

Reviewers: tstellarAMD, arsenm

Subscribers: arsenm

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

llvm-svn: 257591

Summary: ret.ll will contain a test for this

Reviewers: tstellarAMD, arsenm

Subscribers: arsenm

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

llvm-svn: 257590

Make x86 OptimizeLEAs pass remove LEA instruction if there is another LEA
(in the same basic block) which calculates address differing only be a
displacement. Works only for -Oz.

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

llvm-svn: 257589

llvm-svn: 257584

[TableGen] Cleanup output formatting and add llvm_unreachables to the output the AsmMatcher uses when it overflows the 64-bit tables. No in tree targets use this code, but I tested it with an temporarily reduced table width.

llvm-svn: 257583

[TableGen] Replace some hardcoded assumptions that the OpcodeInfo table is 64-bits for cleanliness. NFC

llvm-svn: 257582

llvm-svn: 257581

llvm-svn: 257580

llvm-svn: 257579

llvm-svn: 257578

llvm-svn: 257577

llvm-svn: 257576

This patch turns off the fast-math optimization attribute on the caller
if the callee's fast-math attribute is not turned on.

For example,

- before inlining
 caller: "less-precise-fpmad"="true"
 callee: "less-precise-fpmad"="false"

- after inlining
 caller: "less-precise-fpmad"="false"

Alternatively, it's possible to block inlining if the caller's and
callee's attributes don't match. If this approach is preferable to the
one in this patch, we can discuss post-commit.

rdar://problem/19836465

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

llvm-svn: 257575

Summary:
The problem here is that an enum class can not be implicitly converted to an
integer. That assumption snuck back into PointerIntPair. This commit fixes the
issue and more importantly adds some unittests to make sure that we do not break
this again.

rdar://23594806

Reviewers: gribozavr

Subscribers: llvm-commits

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

llvm-svn: 257574

llvm-svn: 257573

AnalyzeBranch on X86 (and, previously, SPARC, which implementation was
copied from X86) tries to modify the branches based on block
layout (e.g. checking isLayoutSuccessor), when AllowModify is true.

The rest of the architectures leave that up to the caller, which can
call InsertBranch, RemoveBranch, and ReverseBranchCondition as
appropriate. That appears to be the preferred way to do it nowadays.

This commit makes SPARC like the rest: replaces AnalyzeBranch with an
implementation cribbed from AArch64, and adds a ReverseBranchCondition
implementation.

Additionally, a test-case has been added (also cribbed from AArch64)
demonstrating that redundant branch sequences no longer get emitted.

E.g., it used to emit code like this:
         bne .LBB1_2
         nop
         ba .LBB1_1
         nop
 .LBB1_2:

And now emits:
        cmp %i0, 42
        be .LBB1_1
        nop

llvm-svn: 257572

(Resubmit after fixing a typo that breaks test on big endian 
 machines)

In this refactoring, member functions are introduced to access
CovMap header/func record members and hide layout details. This
will enable further code restructuring to support reading multiple
versions of coverage mapping data with shared/templatized code. 
(When coveremap format version changes, backward compatibtility
should be preserved).

llvm-svn: 257571

When we arrive at the end of the function, the validation of
the object has been done already. In theory, so, we should never
arrive here with something broken as the object isn't mutated.
Practice sometimes proves theory to be wrong, so leave an assertion
instead, as suggested by David Blaikie, to catch bugs.

llvm-svn: 257570

llvm-svn: 257564