Original commit message:
Use the SSAUpdator to turn calls to eh.exception that are not in a
landing pad into uses of registers rather than loads from a stack
slot.  Doesn't touch the 'orrible hack code - Bill needs to persuade
me harder :)

llvm-svn: 112952

bootstrap, and clang self-host.

llvm-svn: 112948

llvm-svn: 112947

The cmake (+ MSVC) build is broken if you don't select your native
target.

e.g. 'cmake -D LLVM_TARGETS_TO_BUILD="MyNonNativeTarget" .'

This is because cmake currently sets the LLVM_NATIVE_* definitions
regardless of whether the native target is selected (causing build
errors).

Patch by Mike Gist!

llvm-svn: 112946

The AVX versions of PALIGN and PABS* should only exist for
128-bit. Remove the unnecessary stuff.

llvm-svn: 112944

llvm-svn: 112942

vabd intrinsic and add and/or zext operations.  In the case of vaba, this
also avoids the need for a DAG combine pattern to combine vabd with add.
Update tests.  Auto-upgrade the old intrinsics.

llvm-svn: 112941

llvm-svn: 112938

- Teach getShuffleScalarElt how to handle more target
specific nodes, so the DAGCombine can make use of it.
- Add another hack to avoid the node update problem
during legalization. More description on the comments

llvm-svn: 112934

llvm-svn: 112924

llvm-svn: 112923

llvm-svn: 112921

llvm-svn: 112920

llvm-svn: 112919

stores.

llvm-svn: 112912

llvm-svn: 112910

llvm-svn: 112907

#uses comments, with a testcase.

llvm-svn: 112906

not a scrunched version of it.

llvm-svn: 112904

llvm-svn: 112903

Patch by Cameron Esfahani!

llvm-svn: 112902

comments, these don't happen anymore.

llvm-svn: 112901

Thanks Chris!

llvm-svn: 112900

Remove #uses comments from functions: they we're padded out to column 50
and were potentially confusing for externally visible functions.

going further, remove the "<i8**> [#uses=3]" comments entirely. They
add a lot of noise, confuse people about what the IR is, and don't add 
any particular value.  When the types are long it makes it really really
hard to read IR.

If someone is interested in this sort of thing, the right way to do this
is to implement an AsmAnnotationWriter that produces the same output, and
add a flag to llvm-dis (only) to produce this output.

llvm-svn: 112899

llvm-svn: 112896

llvm-svn: 112895

and were potentially confusing for externally visible functions.

going further, remove the "<i8**> [#uses=3]" comments entirely. They
add a lot of noise, confuse people about what the IR is, and don't add 
any particular value.  When the types are long it makes it really really
hard to read IR.

If someone is interested in this sort of thing, the right way to do this
is to implement an AsmAnnotationWriter that produces the same output, and
add a flag to llvm-dis (only) to produce this output.

llvm-svn: 112894

llvm-svn: 112892

llvm-svn: 112889

I wasn't able to convince myself that all GetMainExecutable
implementations always return absolute paths; this prevents
unexpected behavior in case they ever don't.

llvm-svn: 112888

llvm-svn: 112887

llvm-svn: 112886

llvm-svn: 112885

large local stack areas or require dynamic stack realignment, allocate a
base register via which to access the local frame. This allows efficient
access to frame indices not accessible via the FP (either due to being out
of range or due to dynamic realignment) or the SP (due to variable sized
object allocation). In particular, this greatly improves efficiency of access
to spill slots in Thumb functions which contain VLAs.

rdar://7352504
rdar://8374540
rdar://8355680

llvm-svn: 112883

- Add patterns to match the following MMX builtins:

   * __builtin_ia32_vec_init_v8qi
   * __builtin_ia32_vec_init_v4hi
   * __builtin_ia32_vec_init_v2si
   * __builtin_ia32_vec_ext_v2si

  These builtins do not correspond to a single MMX instruction. They will have
  to be lowered -- most likely in the back-end.

llvm-svn: 112881

llvm-svn: 112878

switches.  Just return the conservatively correct answer.

llvm-svn: 112876

Patch by Jan Sjodin!

llvm-svn: 112875

llvm-svn: 112874

capacity and remove the workaround in SmallVector<T,0>.  There are some
theoretical benefits to a N->2N+1 growth policy anyway.

llvm-svn: 112870