llvm-svn: 119547

llvm-svn: 119546

llvm-svn: 119544

llvm-svn: 119542

llvm-svn: 119539

llvm-svn: 119538

instructions out of InstCombine and into InstructionSimplify.  While
there, introduce an m_AllOnes pattern to simplify matching with integers
and vectors with all bits equal to one.

llvm-svn: 119536

llvm-svn: 119529

llvm-svn: 119515

llvm-svn: 119512

Fixes PR8631.

llvm-svn: 119511

 - No immediate use, but maybe someone feels like hacking on it.

llvm-svn: 119510

llvm-svn: 119509

llvm-svn: 119508

hasConstantValue.  I was leery of using SimplifyInstruction
while the IR was still in a half-baked state, which is the
reason for delaying the simplification until the IR is fully
cooked.

llvm-svn: 119494

phi node itself if it occurs in an unreachable basic block.  Protect
against this.  Hopefully this will fix some more buildbots.

llvm-svn: 119493

llvm-svn: 119492

simplified to itself (this can only happen in unreachable blocks).
Change it to return null instead.  Hopefully this will fix some
buildbot failures.

llvm-svn: 119490

SrcMgrDiagHandler, we can improve clang diagnostics for inline asm:
instead of reporting them on a source line of the original line,
we can report it on the correct line wherever the string literal came
from. For something like this:

void foo() {
  asm("push %rax\n"
      ".code32\n");
}

we used to get this: (note that the line in t.c isn't helpful)

t.c:4:7: error: warning: ignoring directive for now
  asm("push %rax\n"
      ^
<inline asm>:2:1: note: instantiated into assembly here
.code32
^

now we get:

t.c:5:8: error: warning: ignoring directive for now
      ".code32\n"
       ^
<inline asm>:2:1: note: instantiated into assembly here
.code32
^

Note that we're pointing to line 5 properly now.

llvm-svn: 119488

cookie argument to the SourceMgr diagnostic stuff.  This cleanly separates
LLVMContext's inlineasm handler from the sourcemgr error handling 
definition, increasing type safety and cleaning things up.

llvm-svn: 119486

llvm-svn: 119485

llvm-svn: 119484

the cookie argument to setDiagHandler

llvm-svn: 119483

llvm-svn: 119482

llvm-svn: 119463

llvm-svn: 119462

should get the submode from the load/store multiple instruction's opcode.

llvm-svn: 119461

instructions have to distinguish between lists of single- and double-precision
registers in order for the ASM matcher to do a proper job. In all other
respects, a list of single- or double-precision registers are the same as a list
of GPR registers.

llvm-svn: 119460

class, uses DominatorTree which is an analysis.  This change moves all of
the tricky hasConstantValue logic to SimplifyInstruction, and replaces it
with a very simple literal implementation.  I already taught users of
hasConstantValue that need tricky stuff to use SimplifyInstruction instead.
I didn't update InlineFunction because the IR looks like it might be in a
funky state at the point it calls hasConstantValue, which makes calling
SimplifyInstruction dangerous since it can in theory do a lot of tricky
reasoning.  This may be a pessimization, for example in the case where
all phi node operands are either undef or a fixed constant.

llvm-svn: 119459

While there, add a note about an inefficiency I noticed.

llvm-svn: 119458

rather than hasConstantValue.

llvm-svn: 119457

systematically, CollapsePhi will always return null here.  Note
that CollapsePhi did an extra check, isSafeReplacement, which
the SimplifyInstruction logic does not do.  I think that check
was bogus - I guess we will soon find out!  (It was originally
added in commit 41998 without a testcase).

llvm-svn: 119456

This fixes some extreme compile times on unrolled sha512 code.

llvm-svn: 119455

llvm-svn: 119454

operands in a variadic instruction.

llvm-svn: 119446

"getRegisterListOpValue" logic. If the registers are double or single precision,
the value returned is suitable for VLDM/VSTM.

llvm-svn: 119435

llvm-svn: 119433

llvm-svn: 119406

llvm-svn: 119405

No functional change.

llvm-svn: 119404