llvm-svn: 207117

This matches ARM64 behaviour, which I think is clearer. It also puts all the
churn from that difference into one easily ignored commit.

llvm-svn: 207116

Patch by Yuri Gorshenin.

llvm-svn: 207115

Fixes https://code.google.com/p/thread-sanitizer/issues/detail?id=56

llvm-svn: 207114

llvm-svn: 207113

llvm-svn: 207112

llvm-svn: 207111

llvm-svn: 207110

llvm-svn: 207109

We only need assembly support, so it's fairly easy.

llvm-svn: 207108

llvm-svn: 207107

llvm-svn: 207106

These can have different relocations in ELF. In particular both:

    b.eq global
    ldr x0, global

are valid, giving different relocations. The only possible way to distinguish
them is via a different fixup, so the operands had to be separated throughout
the backend.

llvm-svn: 207105

This will also (as with CodeGen) disable testing when the ARM64 backend is not
present.

llvm-svn: 207104

llvm-svn: 207103

ARM64 was not producing pure BFI instructions for bitfield insertion
operations, unlike AArch64. The approach had to be a little different (in
ISelDAGToDAG rather than ISelLowering), and the outcomes aren't identical but
hopefully this gives it similar power.

This should address PR19424.

llvm-svn: 207102

llvm-svn: 207101

Windows Fix: added inttypes.h. Introduces macro redefinition warnings due to LLVM itself externally defining the PRI macros, but now builds on vs2013.

llvm-svn: 207100

[asan] enable use_sigaltstack by default (this will provide verbose reports on stack-overflow instead of silently crashing with SEGV)

llvm-svn: 207099

algorithm here: http://dl.acm.org/citation.cfm?id=177301.

The idea of isolating the roots has even more relevance when using the
stack not just to implement the DFS but also to implement the recursive
step. Because we use it for the recursive step, to isolate the roots we
need to maintain two stacks: one for our recursive DFS walk, and another
of the nodes that have been walked. The nice thing is that the latter
will be half the size. It also fixes a complete hack where we scanned
backwards over the stack to find the next potential-root to continue
processing. Now that is always the top of the DFS stack.

While this is a really nice improvement already (IMO) it further opens
the door for two important simplifications:

1) De-duplicating some of the code across the two different walks. I've
   actually made the duplication a bit worse in some senses with this
   patch because the two are starting to converge.
2) Dramatically simplifying the loop structures of both walks.

I wanted to do those separately as they'll be essentially *just* CFG
restructuring. This patch on the other hand actually uses different
datastructures to implement the algorithm itself.

llvm-svn: 207098

llvm-svn: 207097

llvm-svn: 207096

applied prior to pushing a node onto the DFSStack. This is the first
step toward avoiding the stack entirely for leaf nodes. It also
simplifies things a bit and I think is pointing the way toward factoring
some more of the shared logic out of the two implementations.

It is also making it more obvious how to restructure the loops
themselves to be a bit easier to read (although no different in terms of
functionality).

llvm-svn: 207095

an issue. This way you see that the number of nodes was wrong before
a crash due to accessing too many nodes.

llvm-svn: 207094

Summary:
Correct size_t to be unsigned int and ptrdiff_t to be signed long. The types were the correct size before this change but
the exact type matters for name mangling and exception handling in C++.

Reviewers: atanasyan

Reviewed By: atanasyan

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

llvm-svn: 207093

Patch by Yuri Gorshenin.

llvm-svn: 207092

a SmallPtrSet. Currently, there is no need for stable iteration in this
dimension, and I now thing there won't need to be going forward.

If this is ever re-introduced in any form, it needs to not be
a SetVector based solution because removal cannot be linear. There will
be many SCCs with large numbers of parents. When encountering these, the
incremental SCC update for intra-SCC edge removal was quadratic due to
linear removal (kind of).

I'm really hoping we can avoid having an ordering property here at all
though...

llvm-svn: 207091

can use the node -> SCC mapping in the top-level graph to test this on
the rare occasions we need it.

llvm-svn: 207090

llvm-svn: 207089

This allows us to compile
  return (mask & 0x8 ? a : b);
into
  testb $8, %dil
  cmovnel %edx, %esi
instead of
  andl  $8, %edi
  shrl  $3, %edi
  cmovnel %edx, %esi

which we formed previously because dag combiner canonicalizes setcc of and into shift.

llvm-svn: 207088

llvm-svn: 207087

than pointer iterators.

llvm-svn: 207086

Allow vectorization of few missed llvm intrinsic calls in BBVectorizor by handling them in isVectorizableIntrinsic function.

llvm-svn: 207085

class name usage into a context we can put typename on it.

llvm-svn: 207084

llvm-svn: 207083

template argument to a default argument to the constructor.

llvm-svn: 207082

llvm-svn: 207081

Added support for bytes replication feature, so it could be GAS compatible.

E.g. instructions below:
"vmov.i32 d0, 0xffffffff"
"vmvn.i32 d0, 0xabababab"
"vmov.i32 d0, 0xabababab"
"vmov.i16 d0, 0xabab"
are incorrect, but we could deal with such cases.

For first one we should emit:
"vmov.i8 d0, 0xff"
For second one ("vmvn"):
"vmov.i8 d0, 0x54"
For last two instructions it should emit:
"vmov.i8 d0, 0xab"

P.S.: In ARMAsmParser.cpp I have also fixed few nearby style issues in old code.
Just for keeping method bodies in harmony with themselves.

llvm-svn: 207080

llvm-svn: 207079

value_op_iterator.

llvm-svn: 207078