llvm-svn: 166607

Back out r166591, not sure why this made it through since I cancelled the command. Bleh, sorry about this!

llvm-svn: 166596

Implement a basic VectorTargetTransformInfo interface to be used by the loop and bb vectorizers for modeling the cost of instructions.

llvm-svn: 166593

see the offsetof operator.  Previously, we were matching something like MOVrm
in the front-end and later matching MOVrr in the back-end.  This change makes
things more consistent.  It also fixes cases where we can't match against a 
memory operand as the source (test cases coming).
Part of rdar://12470317

llvm-svn: 166592

llvm-svn: 166591

This checkin also adds in some tests that utilize these paths and updates some of the
clients.

llvm-svn: 166578

llvm-svn: 166566

- If more than 1 elemennts are defined and target supports the vectorized
  conversion, use the vectorized one instead to reduce the strength on
  conversion operation.

llvm-svn: 166546

- As there's no 64-bit GPRs in 32-bit mode, a custom conversion from v2u32 to
  v2f32 is added to improve the efficiency of the code generated.

llvm-svn: 166545

llvm-svn: 166539

the difference from "int x" (which should go in registers and
"struct y {int x;}" (which should not).

Clang will be updated in the next patches.

llvm-svn: 166536

llvm-svn: 166531

called. Provide an (asserting) definition of Operator's private destructor.
Remove destructors from all classes derived from Operator. We don't need them
for safety, because their implicit definitions would be ill-formed (they'd call
Operator's private destructor), and we don't need them to avoid emitting
vtables, because we don't do anything with Operator subclasses which would
trigger vtable instantiation.

The Operator hierarchy is still a complete disaster with regard to undefined
behavior, but this at least allows LLVM to link when using Clang's
-fcatch-undefined-behavior with a new vptr-based type checking mechanism.

llvm-svn: 166530

pointer, not the size of the variable.
Part of rdar://12470317

llvm-svn: 166526

llvm-svn: 166525

non-zero value as we don't know the actual value at this point.  This is
necessary to get the matching correct in some cases.  However, the actual value
set as the base register doesn't matter, since we're just matching not emitting.

llvm-svn: 166523

llvm-svn: 166519

and easier to read by adding a couple helper functions.  Suggestion by
Chandler Carruth and seconded by Meador Inge!

llvm-svn: 166515

- Check index being extracted to be constant 0 before simplfiying.
  Otherwise, retain the original sequence.

llvm-svn: 166504

Make the indirect branch optimization deterministic. No functionality change.

Patch by Daniel Reynaud.

llvm-svn: 166501

llvm-svn: 166494

Use the AliasAnalysis isIdentifiedObj because it also understands mallocs and c++ news.

PR14158.

llvm-svn: 166491

loads. It's not really profitable and may result in GVN going into an infinite
loop when it hits constructs like this:

     %x = gep %some.type %x, ...

Found via an LTO build of LLVM.

llvm-svn: 166490

on patch to r166433.
rdar://12470317

llvm-svn: 166488

- Replace v4i8/v8i8 -> v8f32 DAG combine with custom lowering to reduce
  DAG combine overhead.
- Extend the support to v4i16/v8i16 as well.

llvm-svn: 166487

llvm-svn: 166486

llvm-svn: 166485

for the PowerPC target, and factoring the results.  This will ease future
maintenance of both subtargets.

PPCTargetLowering::LowerCall_Darwin_Or_64SVR4() has grown a lot of special-case
code for the different ABIs, making maintenance difficult.  This is getting
worse as we repair errors in the 64-bit ELF ABI implementation, while avoiding
changes to the Darwin ABI logic.  This patch splits the routine into
LowerCall_Darwin() and LowerCall_64SVR4(), allowing both versions to be
significantly simplified.  I've factored out chunks of similar code where it
made sense to do so.  I also performed similar factoring on
LowerFormalArguments_Darwin() and LowerFormalArguments_64SVR4().

There are no functional changes in this patch, and therefore no new test
cases have been developed.

Built and tested on powerpc64-unknown-linux-gnu with no new regressions.

llvm-svn: 166480

llvm-svn: 166475

 %V = mul i64 %N, 4
 %t = getelementptr i8* bitcast (i32* %arr to i8*), i32 %V
into
 %t1 = getelementptr i32* %arr, i32 %N
 %t = bitcast i32* %t1 to i8*
incorporating the multiplication into the getelementptr.
This happens all the time in dragonegg, for example for
  int foo(int *A, int N) {
    return A[N];
  }
because gcc turns this into byte pointer arithmetic before it hits the plugin:
  D.1590_2 = (long unsigned int) N_1(D);
  D.1591_3 = D.1590_2 * 4;
  D.1592_5 = A_4(D) + D.1591_3;
  D.1589_6 = *D.1592_5;
  return D.1589_6;
The D.1592_5 line is a POINTER_PLUS_EXPR, which is turned into a getelementptr
on a bitcast of A_4 to i8*, so this becomes exactly the kind of IR that the
transform fires on.

An analogous transform (with no testcases!) already existed for bitcasts of
arrays, so I rewrote it to share code with this one.

llvm-svn: 166474

every TU where it's implicitly instantiated, even if there's an implicit
instantiation for the same types available in another TU.

llvm-svn: 166470

llvm-svn: 166467

llvm-svn: 166459

llvm-svn: 166456

llvm-svn: 166454

<rdar://problem/12470345>.

llvm-svn: 166451

The CFG of the machine function needs to know that the targets of the indirect
branch are successors to the indirect branch.
<rdar://problem/12529625>

llvm-svn: 166448

Per the October 12, 2012 Proposal for annotated disassembly output sent out by
Jim Grosbach this set of changes implements this for X86 and arm.  The llvm-mc
tool now has a -mdis option to produced the marked up disassembly and a couple
of small example test cases have been added.

rdar://11764962

llvm-svn: 166445

It's unnecessary and makes the generated assembly less faithful to the original source.

llvm-svn: 166440

Part of rdar://12470317

llvm-svn: 166436