"promote a bunch of load and stores" logic, allowing the code to
be shared and reused.

llvm-svn: 123456

llvm-svn: 123455

    expression (int)[nil_mutable_array count]

within NSArray_expr() function and expect a return of 0.

llvm-svn: 123454

llvm-svn: 123452

The cxx_compiler function should not blindly return clang++ as the C++ compiler if $(CC) contains "clang".
Instead, it should perform a textual replacement of $(CC) from "clang" to "clang++".  The same is true
for "llvm-gcc" to "llvm-g++" and for "gcc" to "g++".  This way, we keep the path component of the $(CC)
passed in from the user and do not end up with a mixed toolchains with different paths.

Ditto for a newly added function called cxx_linker.

llvm-svn: 123451

expansion in it, we may end up instantiating to an empty
expression-list. In this case, the variable is uninitialized; tweak
the instantiation logic to handle this case. Fixes PR8977.

llvm-svn: 123449

expansion, when it is known due to the substitution of an out
parameter pack. This allows us to properly handle substitution into
pack expansions that involve multiple parameter packs at different
template parameter levels, even when this substitution happens one
level at a time (as with partial specializations of member class
templates and the signatures of member function templates).

Note that the diagnostic we provide when there is an arity mismatch
between an outer parameter pack and an inner parameter pack in this
case isn't as clear as the normal diagnostic for an arity
mismatch. However, this doesn't matter because these cases are very,
very rare and (even then) only typically occur in a SFINAE context.

The other kinds of pack expansions (expression, template, etc.) still
need to support optional tracking of the number of expansions, and we
need the moral equivalent of SubstTemplateTypeParmPackType for
substituted argument packs of template template and non-type template
parameters.

llvm-svn: 123448

llvm-svn: 123447

config.h.in.

Patch by arrowdodger!

llvm-svn: 123445

llvm-svn: 123443

simplification present in fully optimized code (I think instcombine fails to
transform some of these when "X-Y" has more than one use).  Fires here and
there all over the test-suite, for example it eliminates 8 subtractions in
the final IR for 445.gobmk, 2 subs in 447.dealII, 2 in paq8p etc.

llvm-svn: 123442

threading of shifts over selects and phis while there.  This fires here and
there in the testsuite, to not much effect.  For example when compiling spirit
it fires 5 times, during early-cse, resulting in 6 more cse simplifications,
and 3 more terminators being folded by jump threading, but the final bitcode
doesn't change in any interesting way: other optimizations would have caught
the opportunity anyway, only later.

llvm-svn: 123441

llvm-svn: 123440

bit-pattern.  Continue punting on zero-initializing VLAs with a nonzero
pattern.

llvm-svn: 123439

replace all uses of the entry with the predecessor.  There are no cleanups
relying on this right now, but if we ever want a cleanup with a phi inside
it, this will be important.

llvm-svn: 123438

early in the cleanup code and one late interlaced with the inliner.  The second one is
important because inlining and other scalar optzns can unpin allocas, allowing them to 
be split up and promoted.  While important for performance, this is also relatively
rare, and we would previously force a (non-lazy) computation of DomFrontiers, which 
happened even if nothing became unpinned.

With this patch, the first pass of scalarrepl still promotes the vast bulk of allocas
in programs, but hte second pass has changed to use SSAUpdater, which is more "sparse"
and lazy.  This speeds up opt -O3 time on kimwitu++ (a c++ app) by about 1%.  The
numbers are interesting: the first pass promotes ~17500 allocas.  The second pass
promotes about 1600.  For non-C++ codes, the compile time win should be greater, 
because the second pass of scalarrepl does less.

llvm-svn: 123437

and one that uses SSAUpdater (-scalarrepl-ssa)

llvm-svn: 123436

static_cast from Constant* to Value* has to adjust the "this" pointer.
This is groundwork for PR889.

llvm-svn: 123435

instead of DomTree/DomFrontier.  This may be interesting for reducing compile 
time.  This is currently disabled, but seems to work just fine.

When this is enabled, we eliminate two runs of dominator frontier, one in the
"early per-function" optimizations and one in the "interlaced with inliner"
function passes.

llvm-svn: 123434

llvm-svn: 123433

This time let's rephrase to trick gcc-4.3 into not miscompiling.

llvm-svn: 123432

llvm-gcc-i386-linux-selfhost buildbot heartburn...

llvm-svn: 123431

llvm-svn: 123430

switch() statements.

llvm-svn: 123429

Anytime we had a valid python list that was trying to go from Python down into
our C++ API, it was allocating too little memory and it ended up smashing
whatever was next to the allocated memory.

Added typemap conversions for "void *, size_t" so we can get 
SBProcess::ReadMemory() working. Also added a typemap for "const void *, size_t"
so we can get SBProcess::WriteMemory() to work.

Fixed an issue in the DWARF parser where we weren't correctly calculating the
DeclContext for all types and classes. We now should be a lot more accurate.
Fixes include: enums should now be setting their parent decl context correctly.
We saw a lot of examples where enums in classes were not being properly
namespace scoped. Also, classes within classes now get properly scoped.

Fixed the objective C runtime pointer checkers to let "nil" pointers through
since these are accepted by compiled code. We also now don't call "abort()"
when a pointer doesn't validate correctly since this was wreaking havoc on
the process due to the way abort() works. We now just dereference memory
which should give us an exception from which we can easily and reliably 
recover.

llvm-svn: 123428

llvm-svn: 123427

llvm-svn: 123426

involve template parameter packs at multiple template levels that
occur within the signatures members of class templates (and partial
specializations thereof). This is a work-in-progress that is deficient
in several ways, notably:
  - It only works for template type parameter packs, but we need to
  also support non-type template parameter packs and template template
  parameter packs.
  - It doesn't keep track of the lengths of the substituted argument
  packs in the expansion, so it can't properly diagnose length
  mismatches.

However, this is a concrete step in the right direction.

llvm-svn: 123425

- Fixed :upper16: fix up routine. It should be shifting down the top 16 bits first.
- Added support for Thumb2 :lower16: and :upper16: fix up.
- Added :upper16: and :lower16: relocation support to mach-o object writer.

llvm-svn: 123424

llvm-svn: 123423

llvm-svn: 123422

llvm-svn: 123421

they should go *before* the new instruction not after it. 

llvm-svn: 123420

Fix some callers to better deal with debug values.

llvm-svn: 123419

most important simplifications, as well as resolving phase ordering issues where instcombine
would inhibit important CSE'ing opportunities, for instance on BitBench/drop3.

llvm-svn: 123418

While there, I noticed that the transform "undef >>a X -> undef" was wrong.
For example if X is 2 then the top two bits must be equal, so the result can
not be anything.  I fixed this in the constant folder as well.  Also, I made
the transform for "X << undef" stronger: it now folds to undef always, even
though X might be zero.  This is in accordance with the LangRef, but I must
admit that it is fairly aggressive.  Also, I added "i32 X << 32 -> undef"
following the LangRef and the constant folder, likewise fairly aggressive.

llvm-svn: 123417

Don't bother conditionalizing the use of SROA in -O1 mode.  We're already running it unconditionally
later in the pipeline.

llvm-svn: 123416

exist within the same process (one script interpreter object per debugger object).  The
python script interpreter objects are all using the same global Python script interpreter;
they use separate dictionaries to keep their data separate, and mutex's to prevent any object
attempting to use the global Python interpreter when another object is already using it.

llvm-svn: 123415

after sext's generated for addressing that got folded.  Previously we compiled
test5 into:

_test5:                                 ## @test5
## BB#0:
        movq    -8(%rsp), %rax          ## 8-byte Reload
        movq    (%rdi,%rax), %rdi
        addq    %rdx, %rdi
        movslq  %esi, %rax
        movq    %rax, -8(%rsp)          ## 8-byte Spill
        movq    %rdi, %rax
        ret

which is insane and wrong.  Now we produce:

_test5:                                 ## @test5
## BB#0:
	movslq	%esi, %rax
	movq	(%rdi,%rax), %rax
	addq	%rdx, %rax
	ret

llvm-svn: 123414

This approach also works when the terminator doesn't have a slot index. (Which
can happen??)

llvm-svn: 123413