- Nov 20, 2013
-
-
Chandler Carruth authored
This adds a new set-like type which represents a set of preserved analysis passes. The set is managed via the opaque PassT::ID() void*s. The expected convenience templates for interacting with specific passes are provided. It also supports a symbolic "all" state which is represented by an invalid pointer in the set. This state is nicely saturating as it comes up often. Finally, it supports intersection which is used when finding the set of preserved passes after N different transforms. The pass API is then changed to return the preserved set rather than a bool. This is much more self-documenting than the previous system. Returning "none" is a conservatively correct solution just like returning "true" from todays passes and not marking any passes as preserved. Passes can also be dynamically preserved or not throughout the run of the pass, and whatever gets returned is the binding state. Finally, preserving "all" the passes is allowed for no-op transforms that simply can't harm such things. Finally, the analysis managers are changed to instead of blindly invalidating all of the analyses, invalidate those which were not preserved. This should rig up all of the basic preservation functionality. This also correctly combines the preservation moving up from one IR-layer to the another and the preservation aggregation across N pass runs. Still to go is incrementally correct invalidation and preservation across IR layers incrementally during N pass runs. That will wait until we have a device for even exposing analyses across IR layers. While the core of this change is obvious, I'm not happy with the current testing, so will improve it to cover at least some of the invalidation that I can test easily in a subsequent commit. llvm-svn: 195241
-
Chandler Carruth authored
Somehow, this ADT got missed which is moderately terrifying considering the efficiency of move for it. The code to implement move semantics for it is pretty horrible currently but was written to reasonably closely match the rest of the code. Unittests that cover both copying and moving (at a basic level) added. llvm-svn: 195239
-
NAKAMURA Takumi authored
llvm-svn: 195238
-
NAKAMURA Takumi authored
llvm-svn: 195237
-
Elena Demikhovsky authored
llvm-svn: 195230
-
Elena Demikhovsky authored
llvm-svn: 195229
-
Chandler Carruth authored
The FunctionPassManager is now itself a function pass. When run over a function, it runs all N of its passes over that function. This is the 1:N mapping in the pass dimension only. This allows it to be used in either a ModulePassManager or potentially some other manager that works on IR units which are supersets of Functions. This commit also adds the obvious adaptor to map from a module pass to a function pass, running the function pass across every function in the module. The test has been updated to use this new pattern. llvm-svn: 195192
-
Yuchen Wu authored
Instead of permanently outputting "MVLL" as the file checksum, clang will create gcno and gcda checksums by hashing the destination block numbers of every arc. This allows for llvm-cov to check if the two gcov files are synchronized. Regenerated the test files so they contain the checksum. Also added negative test to ensure error when the checksums don't match. llvm-svn: 195191
-
Chandler Carruth authored
a module-specific interface. This is the first of many steps necessary to generalize the infrastructure such that we can support both a Module-to-Function and Module-to-SCC-to-Function pass manager nestings. After a *lot* of attempts that never worked and didn't even make it to a committable state, it became clear that I had gotten the layering design of analyses flat out wrong. Four days later, I think I have most of the plan for how to correct this, and I'm starting to reshape the code into it. This is just a baby step I'm afraid, but starts separating the fundamentally distinct concepts of function analysis passes and module analysis passes so that in subsequent steps we can effectively layer them, and have a consistent design for the eventual SCC layer. As part of this, I've started some interface changes to make passes more regular. The module pass accepts the module in the run method, and some of the constructor parameters are gone. I'm still working out exactly where constructor parameters vs. method parameters will be used, so I expect this to fluctuate a bit. This actually makes the invalidation less "correct" at this phase, because now function passes don't invalidate module analysis passes, but that was actually somewhat of a misfeature. It will return in a better factored form which can scale to other units of IR. The documentation has gotten less verbose and helpful. llvm-svn: 195189
-
Hal Finkel authored
Masking operations (where only some number of the low bits are being kept) are selected to rldicl(x, 0, mb). If x is a logical right shift (which would become rldicl(y, 64-n, n)), we might be able to fold the two instructions together: rldicl(rldicl(x, 64-n, n), 0, mb) -> rldicl(x, 64-n, mb) for n <= mb The right shift is really a left rotate followed by a mask, and if the explicit mask is a more-restrictive sub-mask of the mask implied by the shift, only one rldicl is needed. llvm-svn: 195185
-
Eric Christopher authored
and not polymorphically deleted and they are the only thing that derive from DIE. llvm-svn: 195183
-
Eric Christopher authored
and LexicalScopes, we're not using it. llvm-svn: 195182
-
Eric Christopher authored
llvm-svn: 195181
-
Eric Christopher authored
llvm-svn: 195180
-
Jack Carter authored
llvm-svn: 195179
-
Jack Carter authored
llvm-svn: 195175
-
Filip Pizlo authored
llvm-svn: 195173
-
Aditya Nandakumar authored
llvm-svn: 195171
-
Jack Carter authored
llvm-svn: 195170
-
David Blaikie authored
Emit DW_TAG_type_units into the debug_info section using compile unit headers. This is bogus/unusable by debuggers, but testable and provides more isolated review. Subsequent patches will include support for type unit headers and emission into the debug_types section, as well as comdat grouping the types based on their hash. Also the CompileUnit type will be renamed 'Unit' and relevant portions pulled out into respective CompileUnit and TypeUnit types. llvm-svn: 195166
-
- Nov 19, 2013
-
-
David Blaikie authored
DebugInfo: Constify accelerator table handling, and separate type accelarator insertion in preparation for a second use of this code from type units. llvm-svn: 195164
-
Arnold Schwaighofer authored
We are slicing an array of Value pointers and process those slices in a loop. The problem is that we might invalidate a later slice by vectorizing a former slice. Use a WeakVH to track the pointer. If the pointer is deleted or RAUW'ed we can tell. The test case will only fail when running with libgmalloc. radar://15498655 llvm-svn: 195162
-
Arnold Schwaighofer authored
llvm-svn: 195161
-
Petar Jovanovic authored
Instead of processing relocation for branch to stubs right away, emit a modified relocation and add it to queue to be resolved later when final load address is known. This resolves seven MIPS MCJIT issues that were caused by missing relocation fixups at the end. llvm-svn: 195157
-
Juergen Ributzka authored
Reviewed by Tom llvm-svn: 195156
-
Rafael Espindola authored
The object files we support use null terminated strings, so there is no way to support these. This patch adds an assert to catch bad API use and an error check in the .ll parser. llvm-svn: 195155
-
Yuchen Wu authored
llvm-svn: 195153
-
Jack Carter authored
llvm-svn: 195152
-
Yuchen Wu authored
Added constness to methods that shouldn't modify objects. Replaced operator[] lookup in maps with find() instead. llvm-svn: 195151
-
Benjamin Kramer authored
llvm-svn: 195150
-
Rafael Espindola authored
This is the first step to fix pr17918. It extends the .section directive a bit, inspired by what the ELF one looks like. The problem with using linkonce is that given .section foo .linkonce.... .section foo .linkonce we would already have switched sections when getting to .linkonce. The cleanest solution seems to be to add the comdat information in the .section itself. llvm-svn: 195148
-
Andrew Trick authored
Caught by Aaron Ballman. llvm-svn: 195138
-
John Thompson authored
YAML I/O - Added default trait support for std:string. Making another attempt at this, this time doing a clean build on Linux, and running the LLVM, clang, and extra tests, to try to make sure there's no problems. llvm-svn: 195134
-
Cameron McInally authored
llvm-svn: 195129
-
Simon Atanasyan authored
Hard float for mips16 means essentially to compile as soft float but to use a runtime library for soft float that is written with native mips32 floating point instructions (those runtime routines run in mips32 hard float mode). The patch reviewed by Reed Kotler. llvm-svn: 195123
-
Eric Christopher authored
llvm-svn: 195122
-
Eric Christopher authored
llvm-svn: 195121
-
Eric Christopher authored
we can emit various sections in any order. No functional change. llvm-svn: 195120
-
Eric Christopher authored
llvm-svn: 195119
-
Chandler Carruth authored
order of slices of the alloca which have exactly the same size and other properties. This was found by a perniciously unstable sort implementation used to flush out buggy uses of the algorithm. The fundamental idea is that findCommonType should return the best common type it can find across all of the slices in the range. There were two bugs here previously: 1) We would accept an integer type smaller than a byte-width multiple, and if there were different bit-width integer types, we would accept the first one. This caused an actual failure in the testcase updated here when the sort order changed. 2) If we found a bad combination of types or a non-load, non-store use before an integer typed load or store we would bail, but if we found the integere typed load or store, we would use it. The correct behavior is to always use an integer typed operation which covers the partition if one exists. While a clever debugging sort algorithm found problem #1 in our existing test cases, I have no useful test case ideas for #2. I spotted in by inspection when looking at this code. llvm-svn: 195118
-