Sooooo many of these had incorrect or strange main module includes.
I have manually inspected all of these, and fixed the main module
include to be the nearest plausible thing I could find. If you own or
care about any of these source files, I encourage you to take some time
and check that these edits were sensible. I can't have broken anything
(I strictly added headers, and reordered them, never removed), but they
may not be the headers you'd really like to identify as containing the
API being implemented.

Many forward declarations and missing includes were added to a header
files to allow them to parse cleanly when included first. The main
module rule does in fact have its merits. =]

llvm-svn: 169131

llvm-svn: 169130

standards.

I am a terrible Python programmer. Patches more the welcome. Please tell
me how this should look if it should look differently. It's just a tiny
little script so it didn't make sense to go through pre-commit review,
especially as someone who actually knows python may want to just rip it
apart and do it The Right Way.

I will be preparing a commit shortly that uses this script to
canonicalize *all* of the #include lines in LLVM. Really, all of them.

llvm-svn: 169125

The partitioning logic attempted to handle uses of an alloca with an
offset starting before the alloca so long as the use had some overlap
with the alloca itself. However, there was a bug where we tested
'(uint64_t)Offset >= AllocSize' without first checking whether 'Offset'
was positive. As a consequence, essentially every negative offset (that
is, starting *before* the alloca does) would be thrown out, even if it
was overlapping. The subsequent code to throw out negative offsets which
were actually non-overlapping was essentially dead. The code to *handle*
overlapping negative offsets was actually dead!

I've just removed all of this, and taught SROA to discard any uses which
start prior to the alloca from the beginning. It has the lovely property
of simplifying the code. =] All the tests still pass, and in fact no new
tests are needed as this is already covered by our testsuite. Fixing the
code so that negative offsets work the way the comments indicate they
were supposed to work causes regressions. That's how I found this.

Anyways, this is all progress in the correct direction -- tightening up
SROA to be maximally aggressive. Some day, I really hope to turn
out-of-bounds accesses to an alloca into 'unreachable'.

llvm-svn: 169120

llvm-svn: 169119

llvm-svn: 169117

llvm-svn: 169116

This document is a long-time pet peeve :-) More fixes to come.

llvm-svn: 169115

llvm-svn: 169111

llvm-svn: 169110

; CHECK: [[VAR:[a-z]]]

The problem was that to find the end of the regex var definition, it was
simplistically looking for the next ]] and finding the incorrect one. A
better approach is to count nesting of brackets (taking escaping into
account). This way the brackets that are part of the regex can be discovered
and skipped properly, and the ]] ending is detected in the right place.

llvm-svn: 169109

llvm-svn: 169108

trivially achievable with an editor. I'll likely check in a silly python
script to help with this too.

llvm-svn: 169107

llvm-svn: 169106

and recursive copying is not required for the tutorial/ directory.

llvm-svn: 169105

files from tutorial/.svn

llvm-svn: 169104

matching a variable defined on the same line.

llvm-svn: 169103

Patch contributed by Wladimir J. van der Laan <laanwj@gmail.com>

llvm-svn: 169102

See http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20121126/157198.html
and related discussions.

llvm-svn: 169101

llvm-svn: 169091

llvm-svn: 169087

llvm-svn: 169085

Fixes PR14465.

Differential Revision: http://llvm-reviews.chandlerc.com/D148

llvm-svn: 169084

llvm-svn: 169083

Also check in a case to repeat the issue, on which 'opt -globalopt' consumes 1.6GB memory.
The big memory footprint cause is that current GlobalOpt one by one hoists and stores the leaf element constant into the global array, in each iteration, it recreates the global array initializer constant and leave the old initializer alone. This may result in many obsolete constants left.
For example:  we have global array @rom = global [16 x i32] zeroinitializer
After the first element value is hoisted and installed:   @rom = global [16 x i32] [ 1, 0, 0, ... ]
After the second element value is installed:  @rom = global [16 x 32] [ 1, 2, 0, 0, ... ]        // here the previous initializer is obsolete
...
When the transform is done, we have 15 obsolete initializers left useless.

llvm-svn: 169079

2012-11-30-misched-dbg.ll had crashed. Then (MDNode)N was "!{}".
I am not sure it would be ill-formed or not.

llvm-svn: 169074

 - Each macro instantiation introduces a new buffer, and FindBufferForLoc() is
   linear, so previously macro instantiation could be N^2 for some pathological
   inputs.

llvm-svn: 169073

Assertion failed: (TopRPTracker.getPos() == RegionBegin && "bad initial Top tracker").
rdar://12790302.

llvm-svn: 169072

Assertion failed: (VNI && "No value to read by operand")
rdar://12790267.

llvm-svn: 169071

Assertion failed: (itr != mi2iMap.end() && "Instruction not found in maps.")
rdar://12777252.

llvm-svn: 169070

assert (RemainingInstrs == 0 && "Instruction count mismatch!")

rdar://12776937.

llvm-svn: 169069

The TwoAddressInstructionPass takes the machine code out of SSA form by
expanding REG_SEQUENCE instructions into copies. It is no longer
necessary to rewrite the registers used by a REG_SEQUENCE instruction
because the new coalescer algorithm can do it now.

REG_SEQUENCE is just converted to a sequence of sub-register copies now.

llvm-svn: 169067

llvm-svn: 169064

part of the compile unit CU and start separating out information into
the various sections that will be pulled out later.

WIP.

llvm-svn: 169061

MachineCopyPropagation doesn't understand super-register liveness well
enough to be able to remove implicit defs of super-registers.

This fixes a problem in ARM/2012-01-26-CopyPropKills.ll that is exposed
by an future TwoAddressInstructionPass change. The KILL instructions are
removed before the machine code is emitted.

llvm-svn: 169060

llvm-svn: 169056

llvm-svn: 169055

llvm-svn: 169053

llvm-svn: 169052

llvm-svn: 169050