Small patch to the README.txt file which adds a table that shows what compiler
version works on what Power processor. 

Patch by Carlo Bertolli

http://lists.llvm.org/pipermail/openmp-commits/2015-August/000595.html

llvm-svn: 246165

llvm-svn: 246164

http://reviews.llvm.org/D11917

llvm-svn: 246163

llvm-svn: 246162

If a region does not have more than one loop, we do not identify it as
a Scop in ScopDetection. The main optimizations Polly is currently performing
(tiling, preparation for outer-loop vectorization and loop fusion) are unlikely
to have a positive impact on individual loops. In some cases, Polly's run-time
alias checks or conditional hoisting may still have a positive impact, but those
are mostly enabling transformations which LLVM already performs for individual
loops. As we do not focus on individual loops, we leave them untouched to not
introduce compile time regressions and execution time noise. This results in
good compile time reduction (oourafft: -73.99%, smg2000: -56.25%).

Contributed-by: Pratik Bhatu <cs12b1010@iith.ac.in>

Reviewers: grosser

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

llvm-svn: 246161

This should fix the one of the failing bots.

llvm-svn: 246160

Broken by r246155.

llvm-svn: 246159

Constant propagation for single precision math functions (such as
tanf) is already working, but was not enabled. This patch enables
these for many single-precision functions, and adds respective test
cases.

Newly handled functions: acosf asinf atanf atan2f ceilf coshf expf
exp2f fabsf floorf fmodf logf log10f powf sinhf tanf tanhf

llvm-svn: 246158

This improves dependency chain of;

  (LLVMSupport && LLVMTableGen) && (*.cpp in *-tblgen) && (linking *-tblgen)

with;

  (LLVMSupport && LLVMTableGen && *.cpp) && (linking *-tblgen)

llvm-svn: 246156

This is a basic implementation that allows lld to emit binaries
consumable by the HSA runtime.

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

llvm-svn: 246155

llvm-svn: 246154

... in order to avoid conflicts when tests are run in parallel.
This is an attempt to fix PR24591.

llvm-svn: 246153

llvm-svn: 246152

Example output:
File: <stdin>
Format: Mach-O arm
Arch: arm
AddressSize: 32bit
MinVersion {
  Cmd: LC_VERSION_MIN_IPHONEOS
  Size: 16
  Version: 99.8.7
  SDK: n/a
}

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

llvm-svn: 246151

Remove a switch statement, and replace with a bunch of ifs to silence a warning about 'all the enumeration values covered'. No functional change.

llvm-svn: 246150

Unlike scalar operations, we can perform vector operations on element types that
are smaller than the native integer types. We type-promote scalar operations if
they are smaller than a native type (e.g., i8 arithmetic is promoted to i32
arithmetic on Arm targets). This patch detects and removes type-promotions
within the reduction detection framework, enabling the vectorization of small
size reductions.

In the legality phase, we look through the ANDs and extensions that InstCombine
creates during promotion, keeping track of the smaller type. In the
profitability phase, we use the smaller type and ignore the ANDs and extensions
in the cost model. Finally, in the code generation phase, we truncate the result
of the reduction to allow InstCombine to rewrite the entire expression in the
smaller type.

This fixes PR21369.
http://reviews.llvm.org/D12202

Patch by Matt Simpson <mssimpso@codeaurora.org>!

llvm-svn: 246149

This patch fix the function GetTls for aarch64, where it assumes it
follows the x86_64 way where the TLS initial address is at the end
of TLS.  Instead aarch64 set the TLS address as the thread pointer.

llvm-svn: 246148

llvm-svn: 246147

Before:
  Constructor() : initializer(0) {}

  template <typename T>
  Constructor()
      : initializer(0) {}

After:
  Constructor() : initializer(0) {}

  template <typename T>
  Constructor() : initializer(0) {}

llvm-svn: 246146

... and move it into LoopUtils where it can be used by other passes, just like ReductionDescriptor. The API is very similar to ReductionDescriptor - that is, not very nice at all. Sorting these both out will come in a followup.

NFC

llvm-svn: 246145

This change allows the BlockGenerator to be reused in contexts where we want to
provide different/modified isl_ast_expressions, which are not only changed to
a different access relation than the original statement, but which may indeed
be different for each code-generated instance of the statement.

We ensure testing of this feature by moving Polly's support to import changed
access functions through a jscop file to use the BlockGenerators support for
generating arbitary access functions if provided.

This commit should not change the behavior of Polly for now. The diff is rather
large, but most changes are due to us passing the NewAccesses hash table through
functions. This style, even though rather verbose, matches what is done
throughout the BlockGenerator with other per-statement properties.

llvm-svn: 246144

llvm-svn: 246143

  Use ISL to compute the loop trip count when scalar evolution is unable to do
  so.

Contributed-by: Matthew Simpson <mssimpso@codeaurora.org>

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

llvm-svn: 246142

llvm-svn: 246141

llvm-svn: 246140

llvm-svn: 246139

Older OSX versions don't define NSOperatingSystemVersion, so building
lldb gets: error: unknown type name 'NSOperatingSystemVersion'
This patch fixes the build by having GetOSVersionNumbers return false if
__ENVIRONMENT_MAC_OS_X_VERSION_MIN_REQUIRED__ < 101000, causing lldb to
behave the same as it did before the commit.

Reviewed by: jasonmolenda
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D12396

llvm-svn: 246138

Globals in address spaces other than one may have 0 as a valid address,
so we should not assume that they can be null.

Reviewed by Philip Reames.

llvm-svn: 246137

A release fence acts as a publication barrier for stores within the current thread to become visible to other threads which might observe the release fence. It does not require the current thread to observe stores performed on other threads. As a result, we can allow store-load and load-store forwarding across a release fence.

We do need to make sure that stores before the fence can't be eliminated even if there's another store to the same location after the fence. In theory, we could reorder the second store above the fence and *then* eliminate the former, but we can't do this if the stores are on opposite sides of the fence.

Note: While more aggressive then what's there, this patch is still implementing a really conservative ordering.  In particular, I'm not trying to exploit undefined behavior via races, or the fact that the LangRef says only 'atomic' accesses are ordered w.r.t. fences.

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

llvm-svn: 246134

When computing base pointers, we introduce new instructions to propagate the base of existing instructions which might not be bases. However, the algorithm doesn't make any effort to recognize when the new instruction to be inserted is the same as an existing one already in the IR. Since this is happening immediately before rewriting, we don't really have a chance to fix it after the pass runs without teaching loop passes about statepoints.

I'm really not thrilled with this patch. I've rewritten it 4 different ways now, but this is the best I've come up with. The case where the new instruction is just the original base defining value could be merged into the existing algorithm with some complexity. The problem is that we might have something like an extractelement from a phi of two vectors. It may be trivially obvious that the base of the 0th element is an existing instruction, but I can't see how to make the algorithm itself figure that out. Thus, I resort to the call to SimplifyInstruction instead.

Note that we can only adjust the instructions we've inserted ourselves. The live sets are still being tracked in side structures at this point in the code. We can't easily muck with instructions which might be in them. Long term, I'm really thinking we need to materialize the live pointer sets explicitly in the IR somehow rather than using side structures to track them.

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

llvm-svn: 246133

This patch ensures that every analysis diagnostic produced by the vectorizer
will be printed if the loop has a vectorization hint on it. The condition has
also been improved to prevent printing when a disabling hint is specified.

llvm-svn: 246132

Add functionality to the platforms to figure out the proper name for a dynamic library on the system given a basename
This will do things like,
given mylibrary,
return

libmylibrary.dylib on OSX
mylibrary.dll on Windows

and so on for other platforms
It is currently implemented for Windows, Darwin, and Linux. Other platforms should fill in accordingly

llvm-svn: 246131

Switch data formatters over to using std::function for their callbacks instead of raw function pointers. NFC

llvm-svn: 246130

This is a one-line-change patch that moves the update to UnhandledWeights to the correct position: it should be updated for all clusters instead of just range clusters.

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

llvm-svn: 246129

with multiple uses of feature map construction.

Note: We could make this a static function on TargetInfo if we
fix the x86 port needing to check the triple in an isolated case.

llvm-svn: 246128

llvm-svn: 246127

llvm-svn: 246126

As Sanjoy pointed out over in http://reviews.llvm.org/D11819, a switch on an icmp should always be able to become a branch instruction. This patch generalizes that notion slightly to prove that the default case of a switch is unreachable if the cases completely cover all possible bit patterns in the condition. Once that's done, the switch to branch conversion kicks in just fine.

Note: Duplicate case values are disallowed by the LangRef and verifier.

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

llvm-svn: 246125

DeclarationName (because all ctor names are considered the same, and so on).
Reflect this in the type used as the lookup table key. As a side-effect, remove
one copy of the duplicated code used to compute the hash of the key.

llvm-svn: 246124

Summary:
Just `assert("string" && false)` instead of `assert("string" == NULL)`.

This avoid errors like

    [...]\Core\SourceManager.cpp(647): warning C4130: '==' : logical operation on address of string constant

Reviewers: zturner

Subscribers: lldb-commits

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

llvm-svn: 246123