CoalescerPair can determine if a copy can be coalesced, and which register gets
merged away. The old logic in SimpleRegisterCoalescing had evolved into
something a bit too convoluted.

llvm-svn: 106701

when block literal is declared inside a ctor/dtor.
Fixes radr 8096995.

llvm-svn: 106700

llvm-svn: 106699

Do not use "ValueMap" as a name for a local variable or an argument.

llvm-svn: 106698

llvm-svn: 106697

switches the expression parsing over to use the
LLVM IR as opposed to Clang ASTs.  Right now,
that functionality only logs.

llvm-svn: 106695

void t(int *cp0, int *cp1, int *dp, int fmd) {
  int c0, c1, d0, d1, d2, d3;
  c0 = (*cp0++ & 0xffff) | ((*cp1++ << 16) & 0xffff0000);
  c1 = (*cp0++ & 0xffff) | ((*cp1++ << 16) & 0xffff0000);
  /* ... */
}

It code gens into something pretty bad. But with this change (analogous to the
X86 back-end), it will use ldm and generate few instructions.

llvm-svn: 106693

llvm-svn: 106692

when the worklist algorithm has terminated.  This allows some checkers to do a post-analysis
phase after all paths have been analyzed.

llvm-svn: 106689

llvm-svn: 106686

llvm-svn: 106685

llvm-svn: 106683

standard output, resolving a crasher.

llvm-svn: 106682

Add tests for different AVX cmp opcodes, also teach the x86 asm parser to understand the vcmp instruction

llvm-svn: 106678

llvm-svn: 106677

having a library both as bitcode and native code. We want to use the
bitcode first, but if codegen produces new undefined references we have to use
the native code to satisfy those references.

Gold has no notion of bitcode and native search directories, so instead it has
an API where the plugin can instruct it to look for the libraries it is passing
to it. This patch uses that API.

llvm-svn: 106674

llvm-svn: 106672

llvm-svn: 106671

Given the pattern below as an example:
list<dag> Pattern = [(set RC:$dst, (v4f32 (shufp:src3 RC:$src1,
                            (mem_frag addr:$src2))))];

The right reference resolving should lead to:
list<dag> Pattern = [(set VR128:$dst, (v4f32 (shufp:src3 VR128:$src1,
                            (mem_frag addr:$src2))))];
But was yielding:
list<dag> Pattern = [(set VR128:$dst, (v4f32 (shufp VR128:$src1,
                            (mem_frag addr:$src2))))];

Fix this by passing the right name when creating a new DagInit node.

llvm-svn: 106670

llvm-svn: 106668

errors pointed out by John McCall.

llvm-svn: 106665

llvm-svn: 106664

llvm-svn: 106663

branch turns out to be ARM-to-Thumb or vice versa
the linker cannot resolve this.  8120438.

If this optimization is going to be useful we probably
need a compiler flag "assume callees are same architecture"
or something like that.

llvm-svn: 106662

llvm-svn: 106661

into the same node, but with different non-memory operands, we need to replace
the memory operands after it's finished morphing.

llvm-svn: 106643

all the kinks are worked out.

llvm-svn: 106641

llvm-svn: 106640

llvm-svn: 106639

llvm-svn: 106638

Revert r106263, "Fold the ShrinkDemandedOps pass into the regular DAGCombiner pass,"... it was causing both 'file' (with clang) and 176.gcc (with llvm-gcc) to be miscompiled.

llvm-svn: 106634

to using that.

llvm-svn: 106633

MEMBARRIER fences aren't necessary for ARM. Tell the combiner to fold them
away.

llvm-svn: 106631

atomic intrinsics, either because the use locking instructions for the
atomics, or because they perform the locking directly. Add support in the
DAG combiner to fold away the fences.

llvm-svn: 106630

llvm-svn: 106629

llvm-svn: 106628

llvm-svn: 106627

llvm-svn: 106626

llvm-svn: 106625

Modify ClassTemplateSpecializationDecl and ClassTemplatePartialSpecializationDecl to allow PCH read/write.

llvm-svn: 106624