llvm-svn: 187752

Template-template arguments appear to be a rather simple encoding of the
template's templated tag type.

llvm-svn: 187751

We use MVT::i32 for the vector index type, because we use 32-bit
operations to caculate offsets when dynamically indexing vectors.

llvm-svn: 187749

This virtual function can be implemented by targets to specify the type
to use for the index operand of INSERT_VECTOR_ELT, EXTRACT_VECTOR_ELT,
INSERT_SUBVECTOR, EXTRACT_SUBVECTOR.  The default implementation returns
the result from TargetLowering::getPointerTy()

The previous code was using TargetLowering::getPointerTy() for vector
indices, because this is guaranteed to be legal on all targets.  However,
using TargetLowering::getPointerTy() can be a problem for targets with
pointer sizes that differ across address spaces.  On such targets,
when vectors need to be loaded or stored to an address space other than the
default 'zero' address space (which is the address space assumed by
TargetLowering::getPointerTy()), having an index that
is a different size than the pointer can lead to inefficient
pointer calculations, (e.g. 64-bit adds for a 32-bit address space).

There is no intended functionality change with this patch.

llvm-svn: 187748

This reverts commit r187745.

llvm-svn: 187747

http://lab.llvm.org:8011/builders/clang-native-arm-cortex-a9/builds/10248
http://bb.pgr.jp/builders/cmake-clang-i686-mingw32/builds/3327

llvm-svn: 187746

simple.

llvm-svn: 187745

greatly on many comments in the code.

llvm-svn: 187742

MSVC mangles nullptr template arguments identically to zero literals.

llvm-svn: 187741

llvm-svn: 187740

llvm-svn: 187739

This patch was created by Lawrence Crowl and reviewed in:
http://llvm-reviews.chandlerc.com/D963

llvm-svn: 187738

When running the tests under Cygwin using non-Cygwin python,
the platform would be Windows and there would be bash on the path,
so this check for MSYS would not work correctly.

llvm-svn: 187737

Fixed incorrect include file exit detection.  Added work-around to avoid error on header guard in nested include.  Fixed a couple of coding standard issues on variable names.

llvm-svn: 187736

function: it can't be 'void' and it can't be an initializer list. We give a
hard error for these rather than treating them as undefined behavior (we can
and probably should do the same for non-POD types in C++11, but as of this
change we don't).

Slightly rework the checking of variadic arguments in a function with a format
attribute to ensure that certain kinds of format string problem (non-literal
string, too many/too few arguments, ...) don't suppress this error.

llvm-svn: 187735

llvm-svn: 187734

Our internal regex implementation does not cope with large numbers
of anchors very efficiently.  Given a ~3600-entry special case list,
regex compilation can take on the order of seconds.  This patch solves
the problem for the special case of patterns matching literal global
names (i.e. patterns with no regex metacharacters).  Rather than
forming regexes from literal global name patterns, add them to
a StringSet which is checked before matching against the regex.
This reduces regex compilation time by an order of roughly thousands
when reading the aforementioned special case list, according to a
completely unscientific study.

No test cases.  I figure that any new tests for this code should
check that regex metacharacters are properly recognised.  However,
I could not find any documentation which documents the fact that the
syntax of global names in special case lists is based on regexes.
The extent to which regex syntax is supported in special case lists
should probably be decided on/documented before writing tests.

Differential Revision: http://llvm-reviews.chandlerc.com/D1150

llvm-svn: 187732

This will be used to implement an optimisation for literal entries
in special case lists.

Differential Revision: http://llvm-reviews.chandlerc.com/D1278

llvm-svn: 187731

llvm-svn: 187730

Tracked by <rdar://problem/14648821>.

llvm-svn: 187729

SCoP invariant parameters with the different start value would deter parameter
sharing. For example, when compiling the following C code:

  void foo(float *input) {
    for (long j = 0; j < 8; j++) {
      // SCoP begin
      for (long i = 0; i < 8; i++) {
        float x = input[j * 64 + i + 1];
        input[j * 64 + i] = x * x;
      }
    }
  }

Polly would creat two parameters for these memory accesses:

    p_0: {0,+,256}
    p_2: {4,+,256}
    [j * 64 + i + 1] => MemRef_input[o0] : 4o0 = p_1 + 4i0
    [j * 64 + i]     => MemRef_input[o0] : 4o0 = p_0 + 4i0

These parameters only differ from start value. To enable parameter sharing,
we split the start value from SCEVAddRecExpr, so they would share a single
parameter that always has zero start value:

    p0: {0,+,256}<%for.cond1.preheader>
    [j * 64 + i + 1] => MemRef_input[o0] : 4o0 = 4 + p_1 + 4i0
    [j * 64 + i]     => MemRef_input[o0] : 4o0 = p_0 + 4i0

Such translation can make the polly-dependence much faster.

Contributed-by: Star Tan <tanmx_star@yeah.net>
llvm-svn: 187728

llvm-svn: 187727

llvm-svn: 187726

llvm-svn: 187725

LLVM Interpreter: This patch implements vector support for cast operations (zext, sext, uitofp, sitofp, trunc, fpext, fptosi, fptrunc, bitcast) and shift operations (shl, ashr, lshr) for integer and floating point data types.
Added tests.

Done by Yuri Veselov (mailto:Yuri.Veselov@intel.com).

llvm-svn: 187724

This patch just uses a peephole test for "add; compare; branch" sequences
within a single block.  The IR optimizers already convert loops to
decrement-and-branch-on-nonzero form in some cases, so even this
simplistic test triggers many times during a clang bootstrap and
projects/test-suite run.  It looks like there are still cases where we
need to more strongly prefer branches on nonzero though.  E.g. I saw a
case where a loop that started out with a check for 0 ended up with a
check for -1.  I'll try to look at that sometime.

I ended up adding the Reference class because MachineInstr::readsRegister()
doesn't check for subregisters (by design, as far as I could tell).

llvm-svn: 187723

llvm-svn: 187722

llvm-svn: 187721

llvm-svn: 187720

Just the definitions and MC support.  The next patch uses them for codegen.

llvm-svn: 187719

Perhaps predictably, doing comparison elimination on the fly during
SystemZLongBranch turned out to be a bad idea.  The next patches make
use of LOAD AND TEST and BRANCH ON COUNT, both of which require
changes to earlier instructions.

No functionality change intended.

llvm-svn: 187718

Added intrinsics and tests.

llvm-svn: 187717

Use a shuffle with undef elements instead of inserting 0s in the 128-bit to 256-bit casting intrinsics to improve performance. Thanks to Katya Romanova for identifying this issue.

llvm-svn: 187716

Sema::PerformObjectMemberConversion assumed that the Qualifier it was
given holds a type. However, the specifier could hold just a namespace.
In this case, we should ignore the qualifier and not attempt to cast to
it.

llvm-svn: 187715

llvm-svn: 187714

llvm-svn: 187713

helper functions. This can be optimized out later when the remaining
parts of the helper function work is moved into the Mips16HardFloat pass.
For now it forces us to use the 32 bit save/restore instructions instead
of the 16 bit ones.

llvm-svn: 187712

Note that this will require a recent version of the linker for Darwin
builds with LTO to pass these tests.

llvm-svn: 187711

Part of <rdar://problem/14620988>

llvm-svn: 187710

llvm-svn: 187709