This reverts commit e652085eacbec62e4157d08d3f2f875e6e6d5bb4.

llvm-svn: 179172

These instructions aren't universally available, but depend on a specific
extension to the normal ARM architecture (rather than, say, v6/v7/...) so a new
feature is appropriate.

This also enables the feature by default on A-class cores which usually have
these extensions, to avoid breaking existing code and act as a sensible
default.

llvm-svn: 179171

llvm-svn: 179170

rather than checking if the source and destination have the same number of
arguments and copying the attributes over directly.

llvm-svn: 179169

Before we would build huge unwrapped lines which take a long time
to optimze.

llvm-svn: 179168

Before:
class A {
public : // test
};

After:
class A {
public: // test
};

Also remove duplicate methods calculating properties of AnnotatedTokens
and make them members of AnnotatedTokens so that they are in a common
place.

llvm-svn: 179167

Depending on the number of bits set in the writemask.

Signed-off-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
llvm-svn: 179166

Signed-off-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
llvm-svn: 179165

Signed-off-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
llvm-svn: 179164

We handle these by treating this result of the multiplication as an additional
parameter.

llvm-svn: 179163

Implement suggestions made by Bill Schmidt in post-commit review. Thanks!

llvm-svn: 179162

llvm-svn: 179161

llvm-svn: 179160

Regions that have multiple exit edges are very common. A simple if condition
yields e.g. such a region:

        if
      /   \
  then     else
      \   /
      after

Region: if -> after

This regions contains the bbs 'if', 'then', 'else', but not 'after'. It has
two exit edges 'then' -> 'after' and 'else' -> 'after'.

Previously we scheduled the RegionSimplify pass to translate such regions into
simple regions. With this patch, we now support them natively.

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

During code generation we split the original entry and exit basic blocks
of the scop to make room for the newly generated code. To keep the region tree
up to date, we need to update the region tree. This patch ensures that not only
the region of the scop is updated, but also all child regions that share the
same entry or exit block.

We have now test case here, as the bug is only exposed by the subsequent commit.
The test cases of that commit also cover this bug.

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

Contributed by: Star Tan <tanmx_star@yeah.net>

llvm-svn: 179157

This adds in-principle support for if-converting the bctr[l] instructions.
These instructions are used for indirect branching. It seems, however, that the
current if converter will never actually predicate these. To do so, it would
need the ability to hoist a few setup insts. out of the conditionally-executed
block. For example, code like this:
  void foo(int a, int (*bar)()) { if (a != 0) bar(); }
becomes:
        ...
        beq 0, .LBB0_2
        std 2, 40(1)
        mr 12, 4
        ld 3, 0(4)
        ld 11, 16(4)
        ld 2, 8(4)
        mtctr 3
        bctrl
        ld 2, 40(1)
.LBB0_2:
        ...
and it would be safe to do all of this unconditionally with a predicated
beqctrl instruction.

llvm-svn: 179156

Yes, this came from actual code.

Fixes <rdar://problem/13557053>.

llvm-svn: 179155

constructor. This isn't quite perfect (as usual, we don't handle default
arguments correctly yet, and we don't deal with copy/move constructors for
arguments correctly either, but this will be fixed when we implement core issue
1351.

This completes our support for inheriting constructors.

llvm-svn: 179154

The original test case here was mangling a type name for TBAA,
but we can provoke this in C++11 easily enough.

rdar://13434937

llvm-svn: 179153

SectionList so we don't try to do anything with this file.  Currently we end up crashing
later in the debug session when we read past the end of the file -- this at least gets us
closer with something like ProcessMachCore printing "error: core file has no sections".
<rdar://problem/13468295>

llvm-svn: 179152

llvm-svn: 179151

<rdar://problem/13605348> Don't consider invalid user-defined literal operators during overload resolution.

llvm-svn: 179150

llvm-svn: 179149

Fix inspired from c2d4a0627e95c34a819b9d4ffb4db62daa78dade.

    Given the following code

        for (i = 0; i < 10; i++) {
          ;
        }

    S:  A[i] = 0

    When translate the data reference A[i] in statement S using scev, we need to
    retrieve the scev of 'i' at the location of 'S'. If we do not do this the
    scev that we obtain will be expressed as {0,+,1}_for and will reference loop
    iterators that do not surround 'S'. What we really want is the scev to be
    instantiated to the value of 'i' after the loop. This value is {10}.

This used to crash in:

    int loopDimension = getLoopDepth(Expr->getLoop());

    isl_aff *LAff = isl_aff_set_coefficient_si(
        isl_aff_zero_on_domain(LocalSpace), isl_dim_in, loopDimension, 1);

(gdb) p Expr->dump()
{8,+,8}<nw><%do.body>

(gdb) p getLoopDepth(Expr->getLoop())
$5 = 0

    isl_space *Space = isl_space_set_alloc(Ctx, 0, NbLoopSpaces);
    isl_local_space *LocalSpace = isl_local_space_from_space(Space);

As we are trying to create a memory access in a stmt that is outside all loops,
LocalSpace has 0 dimensions:

(gdb) p NbLoopSpaces
$12 = 0

(gdb) p Statement.BB->dump()

if.then:                                          ; preds = %do.end
  %0 = load float* %add.ptr, align 4
  store float %0, float* %q.1.reg2mem, align 4
  br label %if.end.single_exit

and so the scev for %add.ptr should be taken at the place where it is used,
i.e., it should be the value on the last iteration of the do.body loop, and not
"{8,+,8}<nw><%do.body>".

llvm-svn: 179148

For now they are still only used as little endian.

llvm-svn: 179147

llvm-svn: 179146

rdar://13610250

llvm-svn: 179145

part of rdar://13610250

llvm-svn: 179144

[frontend] -frewrite-includes: if there was no inclusion, don't add lineinfo that indicates return from another file.

llvm-svn: 179143

llvm-svn: 179142

xmm0 / xmm1.

rdar://13599493

llvm-svn: 179141

The target hooks are getting out of hand. What does it mean to run
before or after regalloc anyway? Allowing either Pass* or AnalysisID
pass identification should make it much easier for targets to use the
substitutePass and insertPass APIs, and create less need for badly
named target hooks.

llvm-svn: 179140

The GNU line marker directive was sharing code with the #line directive, but some of the warnings/errors were reporting as #line directive diagnostics in both cases.

Previously:
#line 11foo1   ==> "#line directive requires a simple digit sequence"
# 11foo1       ==> "#line directive requires a simple digit sequence"

Now, we get:
#line 11foo1   ==> "#line directive requires a simple digit sequence"
# 11foo1       ==> "GNU line marker directive requires a simple digit sequence"

llvm-svn: 179139

fact be defined and used in another TU.

Reshuffle some test cases because we suppress -Wunused-variable after we've
emitted an error.

This fixes PR15558.

llvm-svn: 179138

if we didn't want to put in a CXXConstructorDecl.  This
prevents malformed classes (i.e., classes with regular C
functions as members) from being generated from type
information (and fixes a crash in the test suite).

<rdar://problem/13550765>

llvm-svn: 179136

Modifier 'D' is to use the second word of a double integer.

We had previously implemented the pure register varient of 
the modifier and this patch implements the memory reference.



#include "stdio.h"

int b[8] = {0,1,2,3,4,5,6,7};
void main()
{
    int i;
    
    // The first word. Notice, no 'D'
    {asm (
    "lw    %0,%1;"
    : "=r" (i)
    : "m" (*(b+4))
    );}
    
    printf("%d\n",i);

    // The second word
    {asm (
    "lw    %0,%D1;"
    : "=r" (i)
    : "m" (*(b+4))
    );}
    
    printf("%d\n",i);
}

llvm-svn: 179135

This enables us to form predicated branches (which are the same conditional
branches we had before) and also a larger set of predicated returns (including
instructions like bdnzlr which is a conditional return and loop-counter
decrement all in one).

At the moment, if conversion does not capture all possible opportunities. A
simple example is provided in early-ret2.ll, where if conversion forms one
predicated return, and then the PPCEarlyReturn pass picks up the other one. So,
at least for now, we'll keep both mechanisms.

llvm-svn: 179134

Fix the help for unwind-on-error, it no longer controls what happens when an expression hits a breakpoint.

llvm-svn: 179133

llvm-svn: 179132