type's bitwidth matches the (allocated) size of the alloca. This severely
pessimizes vector scalar replacement when the only vector type being used is
something like <3 x float> on x86 or ARM whose allocated size matches a
<4 x float>.

I hope to fix some of the flawed assumptions about allocated size throughout
scalar replacement and reenable this in most cases.

llvm-svn: 133338

for pre-2.9 bitcode files.  We keep x86 unaligned loads, movnt, crc32, and the
target indep prefetch change.

As usual, updating the testsuite is a PITA.

llvm-svn: 133337

alloca. Fixes part of <rdar://problem/9580800>.

llvm-svn: 133336

unless ScalarKind is Vector.

llvm-svn: 133335

This should fix the Linux buildbots.

llvm-svn: 133334

Reuse the CodeGenRegBank DenseMap in a few places that would build their
own or use linear search.

llvm-svn: 133333

Targets that need to change the default allocation order should use the
AltOrders mechanism instead. See the X86 and ARM targets for examples.

The allocation_order_begin() and allocation_order_end() methods have been
replaced with getRawAllocationOrder(), and there is further support
functions in RegisterClassInfo.

It is no longer possible to insert arbitrary code into generated
register classes. This is a feature.

llvm-svn: 133332

llvm-svn: 133331

This slightly changes the GPR allocation order on Darwin where R9 is not
a callee-saved register:

Before: %R0 %R1 %R2 %R3 %R12 %R9 %LR %R4 %R5 %R6 %R8 %R10 %R11
After:  %R0 %R1 %R2 %R3 %R9 %R12 %LR %R4 %R5 %R6 %R8 %R10 %R11
llvm-svn: 133326

llvm-svn: 133325

llvm-svn: 133324

llvm-svn: 133321

A register class can define AltOrders and AltOrderSelect instead of
defining method protos and bodies. The AltOrders lists can be defined
with set operations, and TableGen can verify that the alternative
allocation orders only contain valid registers.

This is currently an opt-in feature, and it is still possible to
override allocation_order_begin/end. That will not be true for long.

llvm-svn: 133320

* Make this used only if CFI is used.

llvm-svn: 133319

range without a libcall to a new mulo<mode> libcall
that we'd have to create.

Finishes the rest of rdar://9090077 and rdar://9210061

llvm-svn: 133318

llvm-svn: 133314

llvm-svn: 133313

llvm-svn: 133310

llvm-svn: 133308

llvm-svn: 133307

llvm-svn: 133305

llvm-svn: 133301

llvm-svn: 133299

llvm-svn: 133298

llvm-svn: 133297

the correct values, etc. In particular, the exception handling type is SjLj, not
ARM.

llvm-svn: 133296

llvm-svn: 133293

llvm-svn: 133292

the newly created simple type is valid before checking its legality.
Re-commit the test file.

llvm-svn: 133291

Add an alternative rev16 pattern. We should figure out a better way to handle these complex rev patterns. rdar://9609108

llvm-svn: 133289

calls if we haven't been able to lower them any
other way.

Fixes rdar://9090077 and rdar://9210061

llvm-svn: 133288

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

Followup to 132926.  rdar://problem/9265821

llvm-svn: 133285

llvm-svn: 133275

llvm-svn: 133274

and other backward compatibility hacks.

llvm-svn: 133273

llvm-svn: 133272

llvm-svn: 133271

llvm-svn: 133270

llvm-svn: 133269