Until now all debug info MDNodes referred to a root MDNode, a compile unit. This simplified handling of these needs in dwarf writer.  However, one side effect of this is that during link time optimization all these MDNodes are _not_ uniqued. In other words there will be N number of MDNodes describing "int", "char" and all other types, which would suddenly grow when each object file starts using libraries like STL.

MDNodes graph structure such that compiler unit keeps track of important MDNodes and update dwarf writer to process mdnodes top-down instead of bottom up.

llvm-svn: 137778

making random bad assumptions about instructions which are not explicitly listed.  

Includes fix for rdar://9956541, a version of "undef ^ undef should return
0 because it's easier than arguing with users".

llvm-svn: 137777

llvm-svn: 137775

llvm-svn: 137774

llvm-svn: 137759

llvm-svn: 137757

llvm-svn: 137756

Minor bug in SCCP found by inspection.  (I don't think it's possible to hit this with a normal pass pipeline, but fixing for completeness.)

llvm-svn: 137755

llvm-svn: 137754

llvm-svn: 137751

llvm-svn: 137747

Thumb one requires that many arithmetic instruction forms have an 'S'
suffix. For Thumb2, the whether the suffix is required or precluded depends
on whether the instruction is in an IT block. Use target parser predicates
to check for these sorts of context-sensitive constraints.

llvm-svn: 137746

check for a LandingPadInst.

llvm-svn: 137745

getFirstInsertionPt() returns an iterator to the first insertion point in a
basic block. This is after all PHIs and any other instruction which is required
to be at the top of the basic block (like LandingPadInst).

llvm-svn: 137744

llvm-svn: 137743

llvm-svn: 137742

The argument is unused, and is a layering violation in any case.

llvm-svn: 137735

llvm-svn: 137734

there is no support for native 256-bit shuffles, be more smart in some
cases, for example, when you can extract specific 128-bit parts and use
regular 128-bit shuffles for them. Example:

For this shuffle:
  shufflevector <4 x i64> %a, <4 x i64> %b, <4 x i32>
                <i32 1, i32 0, i32 7, i32 6>

This was expanded to:
  vextractf128  $1, %ymm1, %xmm2
  vpextrq $0, %xmm2, %rax
  vmovd %rax, %xmm1
  vpextrq $1, %xmm2, %rax
  vmovd %rax, %xmm2
  vpunpcklqdq %xmm1, %xmm2, %xmm1
  vpextrq $0, %xmm0, %rax
  vmovd %rax, %xmm2
  vpextrq $1, %xmm0, %rax
  vmovd %rax, %xmm0
  vpunpcklqdq %xmm2, %xmm0, %xmm0
  vinsertf128 $1, %xmm1, %ymm0, %ymm0
  ret

Now we get:
  vshufpd $1, %xmm0, %xmm0, %xmm0
  vextractf128  $1, %ymm1, %xmm1
  vshufpd $1, %xmm1, %xmm1, %xmm1
  vinsertf128 $1, %xmm1, %ymm0, %ymm0

llvm-svn: 137733

llvm-svn: 137728

llvm-svn: 137725

Patch by Kristof Beyls and James Malloy.

llvm-svn: 137723

llvm-svn: 137721

llvm-svn: 137719

Add a mechanism for optimisation plugins to register passes that all front ends can use without needing to be aware of the plugin (or the plugin be aware of the front end).

Before 3.0, I'd like to add a mechanism for automatically loading a set of plugins from a config file.  API suggestions welcome...

llvm-svn: 137717

Thanks to Jonas Gafele for noticing.

llvm-svn: 137716

llvm-svn: 137715

llvm-svn: 137712

Mips1 does not support double precision loads or stores, therefore two single
precision loads or stores must be used in place of these instructions. This 
patch treats double precision loads and stores as if they are legal
instructions until MCInstLowering, instead of generating the single precision
instructions during instruction selection or Prolog/Epilog code insertion.

Without the changes made in this patch, llc produces code that has the same 
problem described in r137484 or bails out when
MipsInstrInfo::storeRegToStackSlot or loadRegFromStackSlot is called before
register allocation.

llvm-svn: 137711

llvm-svn: 137707

llvm-svn: 137706

llvm-svn: 137703

llvm-svn: 137702

FileCheckize. It is more properly an optimizer test.

llvm-svn: 137700

to be wrong (or at least somewhat suspect).  Leave a FIXME for Bill.

llvm-svn: 137694

llvm-svn: 137693

This commit includes a mention of the landingpad instruction, but it's not
changing the behavior around it.  I think the current behavior is correct,
though.  Bill, can you double-check that?

llvm-svn: 137691

llvm-svn: 137690

llvm-svn: 137689

llvm-svn: 137687