that no relocations are used (on MochO).
Fixes llc producing different output from llc + llvm-mc.

llvm-svn: 121000

llvm-svn: 120998

so that's not a valid thing to do at all. Instead, switch to a ValueDecl
argument, the template isn't really necessary here.

When handling the types explicitly in the code, it becomes awkward to cerate
the CXXBaseOrMemberInitializer object in so many places. Re-flow the code to
calculate the Init expression first, and then create the initializer. If this
is too gross, we can factor the init expression logic into helper functions,
but it's not past my threshold yet.

llvm-svn: 120997

reason this is limited to C++, and it's certainly not limited to temporaries.

llvm-svn: 120996

optimization.

Consider:
static void foo() {
  A = alloca
  ...
}

static void bar() {
  B = alloca
  ...
  call foo();
}

void main() {
  bar()
}

The inliner proceeds bottom up, but lets pretend it decides not to inline foo
into bar.  When it gets to main, it inlines bar into main(), and says "hey, I
just inlined an alloca "B" into main, lets remember that.  Then it keeps going
and finds that it now contains a call to foo.  It decides to inline foo into
main, and says "hey, foo has an alloca A, and I have an alloca B from another
inlined call site, lets reuse it".  The problem with this of course, is that 
the lifetime of A and B are nested, not disjoint.

Unfortunately I can't create a reasonable testcase for this: the one in the
PR is both huge and extremely sensitive, because you minor tweaks end up
causing foo to get inlined into bar too early.  We already have tests for the
basic alloca merging optimization and this does not break them.

llvm-svn: 120995

llvm-svn: 120994

llvm-svn: 120993

the LHS, or else the pointer might be invalid.  This is kindof dumb, but
go ahead and make sure we're doing that for l-value scalar assignment,
which fixes a miscompile of obj-c++.dg/block-seq.mm.

Leave a FIXME for how to solve this problem for agg __blocks.

llvm-svn: 120992

llvm-svn: 120991

build one when either of the operands calls itself type-dependent;
previously we were building when one of the operand types was dependent,
which is not always the same thing and which can lead to unfortunate
inconsistencies later.  Fixes PR8739.

llvm-svn: 120990

llvm-svn: 120989

llvm-svn: 120988

llvm-svn: 120987

llvm-svn: 120986

llvm-svn: 120985

implementation needs it for wchar_t and SmallVectorImpl in general.

llvm-svn: 120984

llvm-svn: 120982

that on the ELF writer to detect a section we created.

llvm-svn: 120981

llvm-svn: 120980

llvm-svn: 120979

llvm-svn: 120978

llvm-svn: 120977

Add bug number for current expected failures.

llvm-svn: 120976

more completely. Example expressions are in the comments.

llvm-svn: 120975

memcpy's like:
  memcpy(A, B)
  memcpy(A, C)

we cannot delete the first memcpy as dead if A and C might be aliases.
If so, we actually get:

  memcpy(A, B)
  memcpy(A, A)

which is not correct to transform into:

  memcpy(A, A)

This patch was heavily influenced by Jakub Staszak's patch in PR8728, thanks
Jakub!

llvm-svn: 120974

llvm-svn: 120973

(for example, string literals) were being flagged
erroneously as undefined external variables.

llvm-svn: 120972

llvm-svn: 120971

llvm-svn: 120970

Environment::lookupExpr() and move its implementation
out-of-line.

llvm-svn: 120969

llvm-svn: 120968

Added a less than operator that will compare the internal opaque pointer values so SBBroadcaster objects can be contained in ordered containers or sorted.

llvm-svn: 120967

llvm-svn: 120966

llvm-svn: 120965

llvm-svn: 120964

StrongPHIElimination.

llvm-svn: 120961

difficult on current ARM implementations for a few reasons.
1. Even though a single vmla has latency that is one cycle shorter than a pair
   of vmul + vadd, a RAW hazard during the first (4? on Cortex-a8) can cause
   additional pipeline stall. So it's frequently better to single codegen
   vmul + vadd.
2. A vmla folowed by a vmul, vmadd, or vsub causes the second fp instruction to
   stall for 4 cycles. We need to schedule them apart.
3. A vmla followed vmla is a special case. Obvious issuing back to back RAW
   vmla + vmla is very bad. But this isn't ideal either:
     vmul
     vadd
     vmla
   Instead, we want to expand the second vmla:
     vmla
     vmul
     vadd
   Even with the 4 cycle vmul stall, the second sequence is still 2 cycles
   faster.

Up to now, isel simply avoid codegen'ing fp vmla / vmls. This works well enough
but it isn't the optimial solution. This patch attempts to make it possible to
use vmla / vmls in cases where it is profitable.

A. Add missing isel predicates which cause vmla to be codegen'ed.
B. Make sure the fmul in (fadd (fmul)) has a single use. We don't want to
   compute a fmul and a fmla.
C. Add additional isel checks for vmla, avoid cases where vmla is feeding into
   fp instructions (except for the #3 exceptional case).
D. Add ARM hazard recognizer to model the vmla / vmls hazards.
E. Add a special pre-regalloc case to expand vmla / vmls when it's likely the
   vmla / vmls will trigger one of the special hazards.

Work in progress, only A+B are enabled.

llvm-svn: 120960

llvm-svn: 120959

Clarify some of the differences between indexing with getelementptr and indexing with insertvalue/extractvalue.

llvm-svn: 120957

Also add asserts that the indices are valid in InsertValueInst::init(). ExtractValueInst already asserts when constructed with invalid indices.

llvm-svn: 120956