llvm-svn: 80231

calls into a function and if the calls bring in arrays, try to merge
them together to reduce stack size.  For example, in the testcase
we'd previously end up with 4 allocas, now we end up with 2 allocas.

As described in the comments, this is not really the ideal solution
to this problem, but it is surprisingly effective.  For example, on
176.gcc, we end up eliminating 67 arrays at "gccas" time and another
24 at "llvm-ld" time.

One piece of concern that I didn't look into: at -O0 -g with
forced inlining this will almost certainly result in worse debug
info.  I think this is acceptable though given that this is a case
of "debugging optimized code", and we don't want debug info to
prevent the optimizer from doing things anyway.

llvm-svn: 80215

llvm-svn: 80205

llvm-svn: 80204

a the list of static allocas that it inlined.

llvm-svn: 80203

llvm-svn: 80202

llvm-svn: 80201

and other code cleanups.  No functionality change.

llvm-svn: 80199

llvm-svn: 80198

A    include/llvm/ADT/iterator.cmake
U    autoconf/configure.ac
--- Reverse-merging r80161 into '.':
U    cmake/config-ix.cmake
--- Reverse-merging r80171 into '.':
U    Makefile
--- Reverse-merging r80173 into '.':
U    configure
U    include/llvm/Config/config.h.in
--- Reverse-merging r80180 into '.':
A    include/llvm/ADT/iterator.h.in

Despite common miscomceptions, iterator.h is alive and well. It broke the build
bots for several hours. And yet no one bothered to look at them.

Gabor and Doug, please review your changes and make sure that they actually
build before resubmitting them.

llvm-svn: 80197

do extra checking when it succeeds, as those are cases where
CodeGen will be doing particularly interesting CFG modifications.

llvm-svn: 80196

llvm-svn: 80195

llvm-svn: 80193

members that call methods that read the PoisonMemory member.
This fixes potential spurious (though probably otherwise
harmless) poising of unused memory, and fixes the
associated valgrind error.

llvm-svn: 80192

Fix PR4789. Teach eliminateFrameIndex how to handle VLDRQ and VSTRQ which cannot fold any immediate offset.

llvm-svn: 80191

 - Of course, nothing actually can provide this interface yet.

llvm-svn: 80188

llvm-svn: 80187

llvm-svn: 80186

moves. This avoids the need to promote the operands (or implicitly
extend them, a partial register update condition), and can reduce
i8 register pressure. This substantially speeds up code such as
write_hex in lib/Support/raw_ostream.cpp.

subclass-coalesce.ll is too trivial and no longer tests what it was
originally intended to test.

llvm-svn: 80184

llvm-svn: 80176

llvm-svn: 80170

 - I moved section creation back into AsmParser. I think policy decisions like
   this should be pushed higher, not lower, when possible (in addition the
   assembler has flags which change this behavior, for example).

llvm-svn: 80162

personality function.

llvm-svn: 80153

don't emit the default one. Explicitly check for the NULL
CIE later.

llvm-svn: 80146

llvm-svn: 80145

llvm-svn: 80144

llvm-svn: 80124

llvm-svn: 80121

llvm-svn: 80119

The instructions can be selected directly from the intrinsics.  We will need
to add some ARM-specific nodes for VLD/VST of 3 and 4 128-bit vectors, but
those are not yet implemented.

llvm-svn: 80117

llvm-svn: 80116

llvm-svn: 80115

llvm-svn: 80109

llvm-svn: 80107

backends don't use it as an example.

llvm-svn: 80105

llvm-svn: 80104

this eliminates the ATTRIBUTE_USED, which wasn't being used in a manner
acceptable to some GCC versions, according to the buildbots.

llvm-svn: 80103

(See http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20090817/084958.html)

llvm-svn: 80100

leads to partial-register definitions. To help avoid redundant
zero-extensions, also teach the h-register matching patterns that
use movzbl to match anyext as well as zext.

llvm-svn: 80099

This is a simple AliasAnalysis implementation which works by making
ScalarEvolution queries. ScalarEvolution has a more complete understanding
of arithmetic than BasicAA's collection of ad-hoc checks, so it handles
some cases that BasicAA misses, for example p[i] and p[i+1] within the
same iteration of a loop.

This is currently experimental. It may be that the main use for this pass
will be to help find cases where BasicAA can be profitably extended, or
to help in the development of the overall AliasAnalysis infrastructure,
however it's also possible that it could grow up to become a directly
useful pass.

llvm-svn: 80098