- Dec 03, 2012
-
-
Chandler Carruth authored
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
-
Chris Lattner authored
llvm-svn: 169130
-
Chandler Carruth authored
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
-
Chandler Carruth authored
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
-
Nuno Lopes authored
llvm-svn: 169119
-
Jyotsna Verma authored
llvm-svn: 169117
-
Bill Wendling authored
llvm-svn: 169116
-
Eli Bendersky authored
This document is a long-time pet peeve :-) More fixes to come. llvm-svn: 169115
-
- Dec 02, 2012
-
-
Nadav Rotem authored
llvm-svn: 169111
-
Benjamin Kramer authored
llvm-svn: 169110
-
Eli Bendersky authored
; 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
-
Eli Bendersky authored
llvm-svn: 169108
-
Chandler Carruth authored
trivially achievable with an editor. I'll likely check in a silly python script to help with this too. llvm-svn: 169107
-
Justin Holewinski authored
llvm-svn: 169106
-
- Dec 01, 2012
-
-
Eli Bendersky authored
and recursive copying is not required for the tutorial/ directory. llvm-svn: 169105
-
Eli Bendersky authored
files from tutorial/.svn llvm-svn: 169104
-
Eli Bendersky authored
matching a variable defined on the same line. llvm-svn: 169103
-
Gregory Szorc authored
Patch contributed by Wladimir J. van der Laan <laanwj@gmail.com> llvm-svn: 169102
-
Eli Bendersky authored
See http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20121126/157198.html and related discussions. llvm-svn: 169101
-
James Molloy authored
llvm-svn: 169091
-
Dmitri Gribenko authored
llvm-svn: 169087
-
Benjamin Kramer authored
llvm-svn: 169085
-
Benjamin Kramer authored
Fixes PR14465. Differential Revision: http://llvm-reviews.chandlerc.com/D148 llvm-svn: 169084
-
Zhou Sheng authored
llvm-svn: 169083
-
Zhou Sheng authored
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
-
NAKAMURA Takumi authored
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
-
Daniel Dunbar authored
- 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
-
Andrew Trick authored
Assertion failed: (TopRPTracker.getPos() == RegionBegin && "bad initial Top tracker"). rdar://12790302. llvm-svn: 169072
-
Andrew Trick authored
Assertion failed: (VNI && "No value to read by operand") rdar://12790267. llvm-svn: 169071
-
Andrew Trick authored
Assertion failed: (itr != mi2iMap.end() && "Instruction not found in maps.") rdar://12777252. llvm-svn: 169070
-
Andrew Trick authored
assert (RemainingInstrs == 0 && "Instruction count mismatch!") rdar://12776937. llvm-svn: 169069
-
Jakob Stoklund Olesen authored
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
-
Michael Ilseman authored
llvm-svn: 169064
-
Eric Christopher authored
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
-
Jakob Stoklund Olesen authored
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
-
Eric Christopher authored
llvm-svn: 169056
-
Michael Ilseman authored
llvm-svn: 169055
-
Michael Ilseman authored
llvm-svn: 169053
-
Michael Ilseman authored
llvm-svn: 169052
-
Bill Wendling authored
llvm-svn: 169050
-