llvm-svn: 134930

llvm-svn: 134920

llvm-svn: 134893

  and MCSubtargetInfo.
- Added methods to update subtarget features (used when targets automatically
  detect subtarget features or switch modes).
- Teach X86Subtarget to update MCSubtargetInfo features bits since the
  MCSubtargetInfo layer can be shared with other modules.
- These fixes .code 16 / .code 32 support since mode switch is updated in
  MCSubtargetInfo so MC code emitter can do the right thing.

llvm-svn: 134884

patch brings numerous advantages to LLVM.  One way to look at it
is through diffstat:
 109 files changed, 3005 insertions(+), 5906 deletions(-)

Removing almost 3K lines of code is a good thing.  Other advantages
include:

1. Value::getType() is a simple load that can be CSE'd, not a mutating
   union-find operation.
2. Types a uniqued and never move once created, defining away PATypeHolder.
3. Structs can be "named" now, and their name is part of the identity that
   uniques them.  This means that the compiler doesn't merge them structurally
   which makes the IR much less confusing.
4. Now that there is no way to get a cycle in a type graph without a named
   struct type, "upreferences" go away.
5. Type refinement is completely gone, which should make LTO much MUCH faster
   in some common cases with C++ code.
6. Types are now generally immutable, so we can use "Type *" instead 
   "const Type *" everywhere.

Downsides of this patch are that it removes some functions from the C API,
so people using those will have to upgrade to (not yet added) new API.  
"LLVM 3.0" is the right time to do this.

There are still some cleanups pending after this, this patch is large enough
as-is.

llvm-svn: 134829

CPU, and feature string. Parsing some asm directives can change
subtarget state (e.g. .code 16) and it must be reflected in other
modules (e.g. MCCodeEmitter). That is, the MCSubtargetInfo instance
must be shared.

llvm-svn: 134795

- Each target asm parser now creates its own MCSubtatgetInfo (if needed).
- Changed AssemblerPredicate to take subtarget features which tablegen uses
  to generate asm matcher subtarget feature queries. e.g.
  "ModeThumb,FeatureThumb2" is translated to
  "(Bits & ModeThumb) != 0 && (Bits & FeatureThumb2) != 0".

llvm-svn: 134678

llvm-svn: 134528

llvm-svn: 134525

llvm-svn: 134318

be the first encoded as the first feature. It then uses the CPU name to look up
features / scheduling itineray even though clients know full well the CPU name
being used to query these properties.

The fix is to just have the clients explictly pass the CPU name!

llvm-svn: 134127

llvm-svn: 134049

character in std::string was causing failures for a few ObjC and Obj-C++ tests
when -flto was enabled.  Revision 133999 resolved this issue. Thanks Jay!
rdar://9685235
PR10210

llvm-svn: 134017

avoid getting embedded trailing null bytes in std::strings.

llvm-svn: 133999

This was causing compile-time failures for some of the Objc and Obj-C++
benchmarks.  The specific errors were of the form: "ld: duplicate symbol …"
rdar://9660124

llvm-svn: 133955

llvm-svn: 133872

llvm-svn: 133871

llvm-svn: 133870

llvm-svn: 133516

all over the place in different styles and variants.  Standardize on two
preferred entrypoints: one that takes a StructType and ArrayRef, and one that
takes StructType and varargs.

In cases where there isn't a struct type convenient, we now add a
ConstantStruct::getAnon method (whose name will make more sense after a few
more patches land).  

It would be "really really nice" if the ConstantStruct::get and 
ConstantVector::get methods didn't make temporary std::vectors.

llvm-svn: 133412

removes some gunk from LLVMContext.

llvm-svn: 133360

llvm-svn: 133292

The LSDA is a bit difficult for the non-initiated to read. Even with comments,
it's not always clear what's going on. This wraps the ASM streamer in a class
that retains the LSDA and then emits a human-readable description of what's
going on in it.

So instead of having to make sense of:

Lexception1:
        .byte   255
        .byte   155
        .byte   168
        .space  1
        .byte   3
        .byte   26
Lset0 = Ltmp7-Leh_func_begin1
      .long     Lset0
Lset1 = Ltmp812-Ltmp7
      .long     Lset1
Lset2 = Ltmp913-Leh_func_begin1
      .long     Lset2
      .byte     3
Lset3 = Ltmp812-Leh_func_begin1
      .long     Lset3
Lset4 = Leh_func_end1-Ltmp812
      .long     Lset4
      .long     0
      .byte     0
      .byte     1
      .byte     0
      .byte     2
      .byte     125
      .long     __ZTIi@GOTPCREL+4
      .long     __ZTIPKc@GOTPCREL+4

you can read this instead:

## Exception Handling Table: Lexception1
##  @LPStart Encoding: omit
##    @TType Encoding: indirect pcrel sdata4
##        @TType Base: 40 bytes
## @CallSite Encoding: udata4
## @Action Table Size: 26 bytes

## Action 1:
##   A throw between Ltmp7 and Ltmp812 jumps to Ltmp913 on an exception.
##     For type(s):  __ZTIi@GOTPCREL+4 __ZTIPKc@GOTPCREL+4
## Action 2:
##   A throw between Ltmp812 and Leh_func_end1 does not have a landing pad.

llvm-svn: 133286

llvm-svn: 133274

and other backward compatibility hacks.

llvm-svn: 133273

llvm-svn: 133269

llvm-svn: 133268

llvm-svn: 132913

llvm-svn: 132912

llvm-svn: 132911

Add -O1/2/3 to bugpoint, so when you conclude opt -O2 reproduces an issue, you can just run bugpoint -O2. :)  My implementation isn't precisely equivalent to what opt does, but as far as I can tell, it's close enough.

llvm-svn: 132695

llvm-svn: 132693

from David Meyer's patch!

llvm-svn: 132352

llvm-svn: 132349

llvm-svn: 131947

llvm-svn: 131843

llvm-svn: 131828

llvm-svn: 131824

passes, it should be converted to use extension points.

llvm-svn: 131823

llvm-svn: 131821