- Nov 13, 2013
-
-
Chandler Carruth authored
more smarts in it. This is where most of the interesting logic that used to live in the implicit-scheduling-hackery of the old pass manager will live. Like the previous commits, note that this is a very early prototype! I expect substantial changes before this is ready to use. The core of the design is the following: - We have an AnalysisManager which can be used across a series of passes over a module. - The code setting up a pass pipeline registers the analyses available with the manager. - Individual transform passes can check than an analysis manager provides the analyses they require in order to fail-fast. - There is *no* implicit registration or scheduling. - Analysis passes are different from other passes: they produce an analysis result that is cached and made available via the analysis manager. - Cached results are invalidated automatically by the pass managers. - When a transform pass requests an analysis result, either the analysis is run to produce the result or a cached result is provided. There are a few aspects of this design that I *know* will change in subsequent commits: - Currently there is no "preservation" system, that needs to be added. - All of the analysis management should move up to the analysis library. - The analysis management needs to support at least SCC passes. Maybe loop passes. Living in the analysis library will facilitate this. - Need support for analyses which are *both* module and function passes. - Need support for pro-actively running module analyses to have cached results within a function pass manager. - Need a clear design for "immutable" passes. - Need support for requesting cached results when available and not re-running the pass even if that would be necessary. - Need more thorough testing of all of this infrastructure. There are other aspects that I view as open questions I'm hoping to resolve as I iterate a bit on the infrastructure, and especially as I start writing actual passes against this. - Should we have separate management layers for function, module, and SCC analyses? I think "yes", but I'm not yet ready to switch the code. Adding SCC support will likely resolve this definitively. - How should the 'require' functionality work? Should *that* be the only way to request results to ensure that passes always require things? - How should preservation work? - Probably some other things I'm forgetting. =] Look forward to more patches in shorter order now that this is in place. llvm-svn: 194538
-
- Nov 11, 2013
-
-
Andrew Trick authored
llvm-svn: 194427
-
Benjamin Kramer authored
llvm-svn: 194383
-
- Nov 10, 2013
-
-
David Majnemer authored
llvm-svn: 194341
-
- Nov 09, 2013
-
-
Chandler Carruth authored
give the files a legacy prefix in the right directory. Use forwarding headers in the old locations to paper over the name change for most clients during the transitional period. No functionality changed here! This is just clearing some space to reduce renaming churn later on with a new system. Even when the new stuff starts to go in, it is going to be hidden behind a flag and off-by-default as it is still WIP and under development. This patch is specifically designed so that very little out-of-tree code has to change. I'm going to work as hard as I can to keep that the case. Only direct forward declarations of the PassManager class are impacted by this change. llvm-svn: 194324
-
- Nov 08, 2013
-
-
Bill Wendling authored
llvm-svn: 194251
-
- Nov 07, 2013
-
-
David Majnemer authored
No additional test was needed, Other/constant-fold-gep.ll detects this just fine. llvm-svn: 194221
-
David Majnemer authored
Summary: Consider a GEP of: i8* getelementptr ({ [2 x i8], i32, i8, [3 x i8] }* @main.c, i32 0, i32 0, i64 0) If we proceeded to GEP the aforementioned object by 8, would form a GEP of: i8* getelementptr ({ [2 x i8], i32, i8, [3 x i8] }* @main.c, i32 0, i32 0, i64 8) Note that we would go through the first array member, causing an out-of-bounds accesses. This is problematic because we might get fooled if we are trying to evaluate loads using this GEP, for example, based off of an object with a constant initializer where the array is zero. This fixes PR17732. Reviewers: nicholas, chandlerc, void Reviewed By: void CC: llvm-commits, echristo, void, aemerson Differential Revision: http://llvm-reviews.chandlerc.com/D2093 llvm-svn: 194220
-
- Nov 06, 2013
-
-
Peter Zotov authored
Original patch by Chris Wailes llvm-svn: 194135
-
- Nov 05, 2013
-
-
Rafael Espindola authored
They just propagate out the bitcode reader error, so we don't need a new enum. llvm-svn: 194091
-
Yuchen Wu authored
This reverts commit d8acf0078cf363252727acff00f85ae8074f95b3. llvm-svn: 194040
-
Yuchen Wu authored
This will allow for much easier testing when the input files are in a different folder from the test script. llvm-svn: 194034
-
Yuchen Wu authored
This patch enables llvm-cov to correctly output the run count stored in the GCDA file. GCOVProfiling currently does not generate this information, so the GCDA run data had to be hacked on from a GCDA file generated by gcc. This is corrected by a subsequent patch. With the run and program data included, both llvm-cov and gcov produced the same output. llvm-svn: 194033
-
- Nov 02, 2013
-
-
Yuchen Wu authored
Added -o option to llvm-cov. If no output file is specified, it defaults to STDOUT. llvm-svn: 193899
-
- Nov 01, 2013
-
-
Rafael Espindola authored
linkonce_odr_auto_hide was in incomplete attempt to implement a way for the linker to hide symbols that are known to be available in every TU and whose addresses are not relevant for a particular DSO. It was redundant in that it all its uses are equivalent to linkonce_odr+unnamed_addr. Unlike those, it has never been connected to clang or llvm's optimizers, so it was effectively dead. Given that nothing produces it, this patch just nukes it (other than the llvm-c enum value). llvm-svn: 193865
-
- Oct 31, 2013
-
-
Andrew Trick authored
llvm-svn: 193766
-
- Oct 30, 2013
-
-
Rafael Espindola authored
The function verifyFunction() in lib/IR/Verifier.cpp misses some calls. It creates a temporary FunctionPassManager that will run a single Verifier pass. Unfortunately, FunctionPassManager is no PassManager and does not call doInitialization() and doFinalization() by itself. Verifier does important tasks in doInitialization() such as collecting type information used to check DebugInfo metadata and doFinalization() does some additional checks. Therefore these checks were missed and debug info couldn't be verified at all, it just crashed if the function had some. verifyFunction() is currently not used in llvm unless -debug option is enabled, and in unittests/IR/VerifierTest.cpp VerifierTest had to be changed to create the function in a module from which the type debug info can be collected. Patch by Michael Kruse. llvm-svn: 193719
-
- Oct 29, 2013
-
-
Anders Waldenborg authored
Sorry Peter Zotov, entirely my fault. llvm-svn: 193598
-
Anders Waldenborg authored
Patch by Peter Zotov Differential Revision: http://llvm-reviews.chandlerc.com/D1910 llvm-svn: 193597
-
- Oct 27, 2013
-
-
Shuxin Yang authored
llvm-svn: 193489
-
- Oct 25, 2013
-
-
Yuchen Wu authored
llvm-svn: 193390
-
Yuchen Wu authored
llvm-cov will now be able to read program counts from the GCDA file and output it in the same format as gcov. The program summary tag was identified from gcov-io.h as "\0\0\0\a3". There is currently a bug in GCOVProfiling.cpp which does not generate the run- or program-counting IR, so this change was tested manually by modifying the GCDA file and comparing the gcov and llvm-cov outputs. llvm-svn: 193389
-
- Oct 24, 2013
-
-
Yuchen Wu authored
This was a fundamental flaw in llvm-cov where it treated the values in the GCDA files as block counts instead of edge counts. This created incorrect line counts when branching was present. Instead, the edge counts should be summed to obtain the correct block count. The fix was tested using custom test files as well as single source files from the test-suite directory. The behaviour can be verified by reading the GCOV documentation that describes the GCDA spec ("ARC_COUNTS gives the counter values for those arcs that are instrumented") and the header description provided by GCOVProfiling.cpp ("instruments the code that runs to records (sic) the edges between blocks that run and emit a complementary "gcda" file on exit"). llvm-svn: 193299
-
- Oct 23, 2013
-
-
Yuchen Wu authored
There are a few motivations for this: - Using a map allows for checking if line is in map. This differentiates unexecutable lines (such as comments) from unexecuted logical lines of code. "#####" is now outputted in this case, in line with gcov. - Source files are no longer read in twice: once when storing the line counts, and once when outputting the data. - Greatly simplifies the function FileInfo::addLineCount(). llvm-svn: 193264
-
Shuxin Yang authored
Major steps include: 1). introduces a not-addr-taken bit-field in GlobalVariable 2). GlobalOpt pass sets "not-address-taken" if it proves a global varirable dosen't have its address taken. 3). AA use this info for disambiguation. llvm-svn: 193251
-
Yuchen Wu authored
llvm-svn: 193224
-
- Oct 22, 2013
-
-
Bob Wilson authored
The loop bounds here are uint32_t variables, so it makes sense for the loop variables to have the same type. Patch by Yuchen Wu! llvm-svn: 193192
-
Bob Wilson authored
Rename Size to EndPos, which makes more sense because the variable stores the last location of the blocks. Patch by Yuchen Wu! llvm-svn: 193189
-
Bob Wilson authored
Line counts in llvm-cov are read in as 64-bit integers but were being truncated to 32-bit in collectLineCounts(), which caused overflow for large counts. This patch fixes all counts to be uint64_t. Patch by Yuchen Wu! llvm-svn: 193172
-
Anders Waldenborg authored
Differential Revision: http://llvm-reviews.chandlerc.com/D1963 llvm-svn: 193149
-
Bob Wilson authored
- Replaced tabs with proper padding - print() takes two arguments, which are the GCNO and GCDA filenames - Files are listed at the top of output, appended by line 0 - Stripped strings of trailing \0s - Removed last two lines of whitespace in output Patch by Yuchen Wu! llvm-svn: 193148
-
Bob Wilson authored
collectLineCounts() should only organize the output data. This is done in anticipation of subsequent changes which will pass in GCNO and GCDA filenames into the print function where it is printed similar to the gcov output. Patch by Yuchen Wu! llvm-svn: 193134
-
- Oct 17, 2013
-
-
Michael Kuperstein authored
Solves http://llvm.org/bugs/show_bug.cgi?id=17507 Committed on behalf of alon.mishne@intel.com llvm-svn: 192879
-
- Oct 16, 2013
-
-
Anders Waldenborg authored
The C API currently allows to dump values (LLVMDumpValue), but a similar method for types was not exported. Patch by Peter Zotov Differential Revision: http://llvm-reviews.chandlerc.com/D1911 llvm-svn: 192852
-
Anders Waldenborg authored
Like LLVMDumpModule but returns the string (that needs to be freed with LLVMDisposeMessage) instead of printing it to stderr. Differential Revision: http://llvm-reviews.chandlerc.com/D1941 llvm-svn: 192821
-
Will Dietz authored
Introduce subtype_reverse_iterator to maintain the numbering assigned during the recursive type walk. llvm-svn: 192770
-
Rafael Espindola authored
llvm-svn: 192764
-
Eric Christopher authored
and remove a call to getNonCompileUnitScope as a method shouldn't be in the compile unit scope. llvm-svn: 192748
-
Eric Christopher authored
llvm-svn: 192747
-
- Oct 15, 2013
-
-
Craig Topper authored
Remove x86_sse42_crc32_64_8 intrinsic. It has no functional difference from x86_sse42_crc32_32_8 and was not mapped to a clang builtin. I'm not even sure why this form of the instruction is even called out explicitly in the docs. Also add AutoUpgrade support to convert it into the other intrinsic with appropriate trunc and zext. llvm-svn: 192672
-