llvm-svn: 280745

Summary:
I put this code here, because I want to re-use it in a few other places.
This supersedes some of the immediate folding code we have in SIFoldOperands.
I think the peephole optimizers is probably a better place for folding
immediates into copies, since it does some register coalescing in the same time.

This will also make it easier to transition SIFoldOperands into a smarter pass,
where it looks at all uses of instruction at once to determine the optimal way to
fold operands.  Right now, the pass just considers one operand at a time.

Reviewers: arsenm

Subscribers: wdng, nhaehnle, arsenm, llvm-commits, kzhuravl

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

llvm-svn: 280744

llvm-svn: 280743

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

llvm-svn: 280742

[include-fixer] Fix some Clang-tidy modernize-use-override and Include What You Use warnings; other minor fixes.

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

llvm-svn: 280741

llvm-svn: 280740

This patch provides easy navigation to find the zero count lines, especially useful when the source file is very large.

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

llvm-svn: 280739

Summary:
The only interface that we ever plan to have in this file is
PlatformDevice, so it makes sense to rename the file to reflect that.

Reviewers: jprice

Subscribers: parallel_libs-commits

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

llvm-svn: 280737

Further refine the model for branches.

llvm-svn: 280736

Further refine the model for stores.

llvm-svn: 280735

Further refine the model for loads.

llvm-svn: 280734

llvm-svn: 280733

This adds a copy of the demangler in libcxxabi.

The code also has no dependencies on anything else in LLVM. To enforce
that I added it as another library. That way a BUILD_SHARED_LIBS will
fail if anyone adds an use of StringRef for example.

The no llvm dependency combined with the fact that this has to build
on linux, OS X and Windows required a few changes to the code. In
particular:

    No constexpr.
    No alignas

On OS X at least this library has only one global symbol:
__ZN4llvm16itanium_demangleEPKcPcPmPi

My current plan is:

    Commit something like this
    Change lld to use it
    Change lldb to use it as the fallback

    Add a few #ifdefs so that exactly the same file can be used in
    libcxxabi to export abi::__cxa_demangle.

Once the fast demangler in lldb can handle any names this
implementation can be replaced with it and we will have the one true
demangler.

llvm-svn: 280732

Summary:
Before:
    x!as string
After:
    x! as string

Reviewers: djasper

Subscribers: klimek, cfe-commits

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

llvm-svn: 280731

Summary:
When code contains a comment between `return` and the value:

    return /* lengthy comment here */ (
        lengthyValueComesHere);

Do not wrap before the comment, as that'd break the code through JS' automatic
semicolon insertion.

Reviewers: djasper

Subscribers: klimek, cfe-commits

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

llvm-svn: 280730

This flag is supported by both BFD ld and gold and is occasionally
used to negate the effect of -gc-sections flag.

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

llvm-svn: 280729

When calling getMostRecentDecl, we can pull in more definitions from
a module. We call getPrimaryContext afterwards to make sure that
we buildLookup on a primary context.

rdar://27926200

llvm-svn: 280728

llvm-svn: 280727

Also unbreak newer gcc build with -Werror.

llvm-svn: 280726

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

llvm-svn: 280725

llvm-svn: 280724

llvm-svn: 280722

llvm-svn: 280721

This replaces the threading of `std::string &Error` through all of
these APIs with checked Error returns instead. There are very few
places here that actually emit any errors right now, but threading the
APIs through will allow us to replace a bunch of exit(1)'s that are
scattered through this code with proper error handling.

This is more or less NFC, but does move around where a couple of error
messages are printed out.

llvm-svn: 280720

Summary:
As pointed out by jprice, these classes don't serve a purpose. Instead,
we stay consistent with the way memory is managed and let the Stream and
Kernel classes directly hold opaque handles to device Stream and Kernel
instances, respectively.

Reviewers: jprice, jlebar

Subscribers: parallel_libs-commits

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

llvm-svn: 280719

llvm-svn: 280718

llvm-svn: 280717

llvm-svn: 280716

If we are extracting a subvector that has just been inserted then we should just use the original inserted subvector.

This has come up in certain several x86 shuffle lowering cases where we are crossing 128-bit lanes.

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

llvm-svn: 280715

llvm-svn: 280714

Currently the pass updates branch weights in the IR if the function has
any PGO info (entry frequency is set).  However we could still have
regions of the CFG that does not have branch weights collected (e.g. a
cold region).  In this case we'd use static estimates.  Since static
estimates for branches are determined independently, they are
inconsistent.  Updating them can "randomly" inflate block frequencies.

I've run into this in a completely cold loop of h264ref from
SPEC.  -Rpass-with-hotness showed the loop to be completely cold during
inlining (before JT) but completely hot during vectorization (after JT).

The new testcase demonstrate the problem.  We check array elements
against 1, 2 and 3 in a loop.  The check against 3 is the loop-exiting
check.  The block names should be self-explanatory.

In this example, jump threading incorrectly updates the weight of the
loop-exiting branch to 0, drastically inflating the frequency of the
loop (in the range of billions).

There is no run-time profile info for edges inside the loop, so branch
probabilities are estimated.  These are the resulting branch and block
frequencies for the loop body:

                check_1 (16)
            (8) /  |
            eq_1   | (8)
                \  |
                check_2 (16)
            (8) /  |
            eq_2   | (8)
                \  |
                check_3 (16)
            (1) /  |
       (loop exit) | (15)
                   |
              (back edge)

First we thread eq_1 -> check_2 to check_3.  Frequencies are updated to
remove the frequency of eq_1 from check_2 and then from the false edge
leaving check_2.  Changed frequencies are highlighted with * *:

                check_1 (16)
            (8) /  |
           eq_1~   | (8)
           /       |
          /     check_2 (*8*)
         /  (8) /  |
         \  eq_2   | (*0*)
          \     \  |
           ` --- check_3 (16)
            (1) /  |
       (loop exit) | (15)
                   |
              (back edge)

Next we thread eq_1 -> check_3 and eq_2 -> check_3 to check_1 as new
back edges.  Frequencies are updated to remove the frequency of eq_1 and
eq_3 from check_3 and then the false edge leaving check_3 (changed
frequencies are highlighted with * *):

                  check_1 (16)
              (8) /  |
             eq_1~   | (8)
             /       |
            /     check_2 (*8*)
           /  (8) /  |
          /-- eq_2~  | (*0*)
  (back edge)        |
                  check_3 (*0*)
            (*0*) /  |
         (loop exit) | (*0*)
                     |
                (back edge)

As a result, the loop exit edge ends up with 0 frequency which in turn makes
the loop header to have maximum frequency.

There are a few potential problems here:

1. The profile data seems odd.  There is a single profile sample of the
loop being entered.  On the other hand, there are no weights inside the
loop.

2. Based on static estimation we shouldn't set edges to "extreme"
values, i.e. extremely likely or unlikely.

3. We shouldn't create profile metadata that is calculated from static
estimation.  I am not sure what policy is but it seems to make sense to
treat profile metadata as something that is known to originate from
profiling.  Estimated probabilities should only be reflected in BPI/BFI.

Any one of these would probably fix the immediate problem.  I went for 3
because I think it's a good policy to have and added a FIXME about 2.

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

llvm-svn: 280713

llvm-svn: 280711

[Sparc][Leon] Corrected supported atomics size for processors supporting Leon CASA instruction back to 32 bits.

This was erroneously checked-in for 64 bits while trying to find if there was a way to get 64 bit atomicity in Leon processors. There is not and this change should not have been checked-in. There is no unit test for this as the existing unit tests test for behaviour to 32 bits, which was the original intention of the code.

llvm-svn: 280710

Fixes pr30282.

llvm-svn: 280709

Patch implements FILL just as alias for =fillexpr. 
This allows to make implementation much shorted and simpler than D24186.

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

llvm-svn: 280708

MSVC emits an error when one uses a const variable in a lambda without
capturing it.

gcc and clang don't emit an error in this scenario.

llvm-svn: 280707

LLVM PR/29052 highlighted that FastISel for MIPS attempted to lower
arguments assuming that it was using the paired 32bit registers to
perform operations for f64. This mode of operation is not supported
for MIPSR6.

This patch resolves the reported issue by adding additional checks
for unsupported floating point unit configuration.

Thanks to mike.k for reporting this issue!

Reviewers: seanbruno, vkalintiris

Differential Review: https://reviews.llvm.org/D23795

llvm-svn: 280706

Unlike PPC64, PPC32/SVRV4 does not have red zone. In the absence of it 
there is no guarantee that this part of the stack will not be modified 
by any interrupt. To avoid this, make sure to claim the stack frame first
before storing into it.

This fixes https://llvm.org/bugs/show_bug.cgi?id=26519.

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

llvm-svn: 280705

Android targets don't have std::to_string and std::stoul. Use llvm::to_string and strtoul
instead.

llvm-svn: 280704

This reverts commit rL280668 because the register tests fail on i386
Linux.

I investigated a little bit what causes the failure - there are missing
registers when running 'register read -a'.
This is the output I got at the bottom:
"""
...
Memory Protection Extensions:
      bnd0 = {0x0000000000000000 0x0000000000000000}
      bnd1 = {0x0000000000000000 0x0000000000000000}
      bnd2 = {0x0000000000000000 0x0000000000000000}
      bnd3 = {0x0000000000000000 0x0000000000000000}

unknown:
2 registers were unavailable.
"""

Also looking at the packets exchanged between the client and server:
"""
...
history[308] tid=0x7338 <  19> send packet: $qRegisterInfo4a#d7
history[309] tid=0x7338 < 130> read packet:
$name:bnd0;bitsize:128;offset:1032;encoding:vector;format:vector-uint64;set:Memory
Protection Extensions;ehframe:101;dwarf:101;#48
history[310] tid=0x7338 <  19> send packet: $qRegisterInfo4b#d8
history[311] tid=0x7338 < 130> read packet:
$name:bnd1;bitsize:128;offset:1048;encoding:vector;format:vector-uint64;set:Memory
Protection Extensions;ehframe:102;dwarf:102;#52
history[312] tid=0x7338 <  19> send packet: $qRegisterInfo4c#d9
history[313] tid=0x7338 < 130> read packet:
$name:bnd2;bitsize:128;offset:1064;encoding:vector;format:vector-uint64;set:Memory
Protection Extensions;ehframe:103;dwarf:103;#53
history[314] tid=0x7338 <  19> send packet: $qRegisterInfo4d#da
history[315] tid=0x7338 < 130> read packet:
$name:bnd3;bitsize:128;offset:1080;encoding:vector;format:vector-uint64;set:Memory
Protection Extensions;ehframe:104;dwarf:104;#54
history[316] tid=0x7338 <  19> send packet: $qRegisterInfo4e#db
history[317] tid=0x7338 <  76> read packet:
$name:bndcfgu;bitsize:64;offset:1096;encoding:vector;format:vector-uint8;#99
history[318] tid=0x7338 <  19> send packet: $qRegisterInfo4f#dc
history[319] tid=0x7338 <  78> read packet:
$name:bndstatus;bitsize:64;offset:1104;encoding:vector;format:vector-uint8;#8e
...
"""

The bndcfgu and bndstatus registers don't have the 'Memory Protections
Extension' set. I looked at the code and it seems that that is set
correctly.

So I'm not sure what's the problem or where does it come from.

Also there is a second failure related to something like this in the
tests:
"""
registerSet.GetName().lower()
"""

For some reason the registerSet.GetName() returns None.

llvm-svn: 280703