summaryrefslogtreecommitdiffstats
path: root/llvm/tools
Commit message (Collapse)AuthorAgeFilesLines
* Move DataLayout back to the TargetMachine from TargetSubtargetInfoEric Christopher2015-01-261-1/+1
| | | | | | | | | | | | | | | | | | | derived classes. Since global data alignment, layout, and mangling is often based on the DataLayout, move it to the TargetMachine. This ensures that global data is going to be layed out and mangled consistently if the subtarget changes on a per function basis. Prior to this all targets(*) have had subtarget dependent code moved out and onto the TargetMachine. *One target hasn't been migrated as part of this change: R600. The R600 port has, as a subtarget feature, the size of pointers and this affects global data layout. I've currently hacked in a FIXME to enable progress, but the port needs to be updated to either pass the 64-bitness to the TargetMachine, or fix the DataLayout to avoid subtarget dependent features. llvm-svn: 227113
* [ELFYAML] Support mips64 relocation record format in yaml2obj/obj2yamlSimon Atanasyan2015-01-251-2/+8
| | | | | | | | | | | | | | | | | | | MIPS64 ELF file has a very specific relocation record format. Each record might specify up to three relocation operations. So the `r_info` field in fact consists of three relocation type sub-fields and optional code of "special" symbols. http://techpubs.sgi.com/library/manuals/4000/007-4658-001/pdf/007-4658-001.pdf page 40 The patch implements support of the MIPS64 relocation record format in yaml2obj/obj2yaml tools by introducing new optional Relocation fields: Type2, Type3, and SpecSym. These fields are recognized only if the object/YAML file relates to the MIPS64 target. Differential Revision: http://reviews.llvm.org/D7136 llvm-svn: 227044
* Update of the gold-plugin.cpp code to match Chandler's changes (r226981)Sylvestre Ledru2015-01-241-1/+1
| | | | llvm-svn: 227004
* [PM] Port LowerExpectIntrinsic to the new pass manager.Chandler Carruth2015-01-242-0/+2
| | | | | | | | | | | | This just lifts the logic into a static helper function, sinks the legacy pass to be a trivial wrapper of that helper fuction, and adds a trivial wrapper for the new PM as well. Not much to see here. I switched a test case to run in both modes, but we have to strip the dead prototypes separately as that pass isn't in the new pass manager (yet). llvm-svn: 226999
* [PM] Port instcombine to the new pass manager!Chandler Carruth2015-01-242-0/+2
| | | | | | | | | | | | | | | | | | | | This is exciting as this is a much more involved port. This is a complex, existing transformation pass. All of the core logic is shared between both old and new pass managers. Only the access to the analyses is separate because the actual techniques are separate. This also uses a bunch of different and interesting analyses and is the first time where we need to use an analysis across an IR layer. This also paves the way to expose instcombine utility functions. I've got a static function that implements the core pass logic over a function which might be mildly interesting, but more interesting is likely exposing a routine which just uses instructions *already in* the worklist and combines until empty. I've switched one of my favorite instcombine tests to run with both as well to make sure this keeps working. llvm-svn: 226987
* [PM] Rework how the TargetLibraryInfo pass integrates with the new passChandler Carruth2015-01-243-6/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | manager to support the actual uses of it. =] When I ported instcombine to the new pass manager I discover that it didn't work because TLI wasn't available in the right places. This is a somewhat surprising and/or subtle aspect of the new pass manager design that came up before but I think is useful to be reminded of: While the new pass manager *allows* a function pass to query a module analysis, it requires that the module analysis is already run and cached prior to the function pass manager starting up, possibly with a 'require<foo>' style utility in the pass pipeline. This is an intentional hurdle because using a module analysis from a function pass *requires* that the module analysis is run prior to entering the function pass manager. Otherwise the other functions in the module could be in who-knows-what state, etc. A somewhat surprising consequence of this design decision (at least to me) is that you have to design a function pass that leverages a module analysis to do so as an optional feature. Even if that means your function pass does no work in the absence of the module analysis, you have to handle that possibility and remain conservatively correct. This is a natural consequence of things being able to invalidate the module analysis and us being unable to re-run it. And it's a generally good thing because it lets us reorder passes arbitrarily without breaking correctness, etc. This ends up causing problems in one case. What if we have a module analysis that is *definitionally* impossible to invalidate. In the places this might come up, the analysis is usually also definitionally trivial to run even while other transformation passes run on the module, regardless of the state of anything. And so, it follows that it is natural to have a hard requirement on such analyses from a function pass. It turns out, that TargetLibraryInfo is just such an analysis, and InstCombine has a hard requirement on it. The approach I've taken here is to produce an analysis that models this flexibility by making it both a module and a function analysis. This exposes the fact that it is in fact safe to compute at any point. We can even make it a valid CGSCC analysis at some point if that is useful. However, we don't want to have a copy of the actual target library info state for each function! This state is specific to the triple. The somewhat direct and blunt approach here is to turn TLI into a pimpl, with the state and mutators in the implementation class and the query routines primarily in the wrapper. Then the analysis can lazily construct and cache the implementations, keyed on the triple, and on-demand produce wrappers of them for each function. One minor annoyance is that we will end up with a wrapper for each function in the module. While this is a bit wasteful (one pointer per function) it seems tolerable. And it has the advantage of ensuring that we pay the absolute minimum synchronization cost to access this information should we end up with a nice parallel function pass manager in the future. We could look into trying to mark when analysis results are especially cheap to recompute and more eagerly GC-ing the cached results, or we could look at supporting a variant of analyses whose results are specifically *not* cached and expected to just be used and discarded by the consumer. Either way, these seem like incremental enhancements that should happen when we start profiling the memory and CPU usage of the new pass manager and not before. The other minor annoyance is that if we end up using the TLI in both a module pass and a function pass, those will be produced by two separate analyses, and thus will point to separate copies of the implementation state. While a minor issue, I dislike this and would like to find a way to cleanly allow a single analysis instance to be used across multiple IR unit managers. But I don't have a good solution to this today, and I don't want to hold up all of the work waiting to come up with one. This too seems like a reasonable thing to incrementally improve later. llvm-svn: 226981
* [Orc] Add orcjit to the dependencies list in the Makefile for lli.Lang Hames2015-01-241-1/+1
| | | | | | This should fix a few more broken bots. llvm-svn: 226973
* llvm-cov: Don't use llvm::outs() in library codeJustin Bogner2015-01-231-1/+1
| | | | | | | Nothing in lib/ should be using llvm::outs() directly. Thread it in from the caller instead. llvm-svn: 226961
* [Orc] New JIT APIs.Lang Hames2015-01-232-0/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch adds a new set of JIT APIs to LLVM. The aim of these new APIs is to cleanly support a wider range of JIT use cases in LLVM, and encourage the development and contribution of re-usable infrastructure for LLVM JIT use-cases. These APIs are intended to live alongside the MCJIT APIs, and should not affect existing clients. Included in this patch: 1) New headers in include/llvm/ExecutionEngine/Orc that provide a set of components for building JIT infrastructure. Implementation code for these headers lives in lib/ExecutionEngine/Orc. 2) A prototype re-implementation of MCJIT (OrcMCJITReplacement) built out of the new components. 3) Minor changes to RTDyldMemoryManager needed to support the new components. These changes should not impact existing clients. 4) A new flag for lli, -use-orcmcjit, which will cause lli to use the OrcMCJITReplacement class as its underlying execution engine, rather than MCJIT itself. Tests to follow shortly. Special thanks to Michael Ilseman, Pete Cooper, David Blaikie, Eric Christopher, Justin Bogner, and Jim Grosbach for extensive feedback and discussion. llvm-svn: 226940
* Fix the problem with llvm-objdump and -archive-headers in printing the ↵Kevin Enderby2015-01-231-1/+1
| | | | | | | | archive header size field. This problem showed up with the clang-cmake-armv7-a15-full bot. Thanks to Renato Golin for his help. llvm-svn: 226936
* [Objdump] Output information about common symbols in a way closer to GNU ↵Colin LeMahieu2015-01-231-1/+11
| | | | | | objdump. llvm-svn: 226932
* Add the option, -data-in-code, to llvm-objdump used with -macho to print the ↵Kevin Enderby2015-01-233-2/+53
| | | | | | Mach-O data in code table. llvm-svn: 226921
* Add STB_GNU_UNIQUE to the ELF writer.Rafael Espindola2015-01-231-3/+4
| | | | | | This lets llvm-mc assemble files produced by gcc. llvm-svn: 226895
* [PM] Actually add the new pass manager support for the assumption cache.Chandler Carruth2015-01-222-0/+3
| | | | | | | | | | | | | | | I had already factored this analysis specifically to enable doing this, but hadn't actually committed the necessary wiring to get at this from the new pass manager. This also nicely shows how the separate cache object can be directly managed by the new pass manager. This analysis didn't have any direct tests and so I've added a printer pass and a boring test case. I chose to print the i1 value which is being assumed rather than the call to llvm.assume as that seems much more useful for testing... but suggestions on an even better printing strategy welcome. My main goal was to make sure things actually work. =] llvm-svn: 226868
* Add the option, -indirect-symbols, used with -macho to print the Mach-O ↵Kevin Enderby2015-01-223-3/+136
| | | | | | indirect symbol table to llvm-objdump. llvm-svn: 226848
* Assigning and copying command line option objects shouldn't be allowed.Chris Bieneman2015-01-223-4/+6
| | | | | | | | | | | | | | | Summary: The default copy and assignment operators for these objects probably don't actually do what the clients intend, so they should be deleted. Places using the assignment operator to set the value of an option should cast to the option's data type first to call into the override for operator=. Places using the copy constructor just need to be changed to not copy (i.e. passing by const reference instead of value). Reviewers: dexonsmith, chandlerc Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D7114 llvm-svn: 226762
* For llvm-objdump, hook up existing options to work when using -macho (the ↵Kevin Enderby2015-01-203-29/+34
| | | | | | Mach-O parser). llvm-svn: 226612
* [PM] Port LoopInfo to the new pass manager, adding both a LoopAnalysisChandler Carruth2015-01-202-0/+3
| | | | | | | | | | | | | | pass and a LoopPrinterPass with the expected associated wiring. I've added a RUN line to the only test case (!!!) we have that actually prints loops. Everything seems to be working. This is somewhat exciting as this is the first analysis using another analysis to go in for the new pass manager. =D I also believe it is the last analysis necessary for porting instcombine, but of course I may yet discover more. llvm-svn: 226560
* [dsymutil] Add the detected target triple to the debug map.Frederic Riss2015-01-193-2/+16
| | | | | | | It will be needed to instantiate the Target object that we will use to create all the MC objects for the dwarf emission. llvm-svn: 226525
* unique_ptrify the RelInfo parameter to TargetRegistry::createMCSymbolizerDavid Blaikie2015-01-181-2/+2
| | | | llvm-svn: 226416
* Fix the Archive::Child::getRawSize() method used by llvm-objdump’s ↵Kevin Enderby2015-01-161-1/+1
| | | | | | | | -archive-headers option and tweak its use in llvm-objdump. Add back the test case for the -archive-headers option. llvm-svn: 226332
* llvm-readobj: add IMAGE_REL_ARM_MOV32(T) to the enumerationSaleem Abdulrasool2015-01-161-0/+1
| | | | | | | Add an additional based relocation to the enumeration of based relocation names. The lack of the enumerator value causes issues when inspecting WoA binaries. llvm-svn: 226314
* Add the option, -archive-headers, used with -macho to print the Mach-O ↵Kevin Enderby2015-01-153-3/+118
| | | | | | archive headers to llvm-objdump. llvm-svn: 226228
* [PM] Port TargetLibraryInfo to the new pass manager, provided by theChandler Carruth2015-01-152-0/+2
| | | | | | | | | | | | | | | | | | | | TargetLibraryAnalysis pass. There are actually no direct tests of this already in the tree. I've added the most basic test that the pass manager bits themselves work, and the TLI object produced will be tested by an upcoming patches as they port passes which rely on TLI. This is starting to point out the awkwardness of the invalidate API -- it seems poorly fitting on the *result* object. I suspect I will change it to live on the analysis instead, but that's not for this change, and I'd rather have a few more passes ported in order to have more experience with how this plays out. I believe there is only one more analysis required in order to start porting instcombine. =] llvm-svn: 226160
* [PM] Separate the TargetLibraryInfo object from the immutable pass.Chandler Carruth2015-01-152-6/+8
| | | | | | | | | | | | | | The pass is really just a means of accessing a cached instance of the TargetLibraryInfo object, and this way we can re-use that object for the new pass manager as its result. Lots of delta, but nothing interesting happening here. This is the common pattern that is developing to allow analyses to live in both the old and new pass manager -- a wrapper pass in the old pass manager emulates the separation intrinsic to the new pass manager between the result and pass for analyses. llvm-svn: 226157
* Update libdeps since TLI was moved from Target to Analysis in r226078.NAKAMURA Takumi2015-01-151-1/+1
| | | | llvm-svn: 226126
* [PM] Move TargetLibraryInfo into the Analysis library.Chandler Carruth2015-01-153-3/+3
| | | | | | | | | | | | | | | | While the term "Target" is in the name, it doesn't really have to do with the LLVM Target library -- this isn't an abstraction which LLVM targets generally need to implement or extend. It has much more to do with modeling the various runtime libraries on different OSes and with different runtime environments. The "target" in this sense is the more general sense of a target of cross compilation. This is in preparation for porting this analysis to the new pass manager. No functionality changed, and updates inbound for Clang and Polly. llvm-svn: 226078
* Fix linking of shared libraries.Rafael Espindola2015-01-141-1/+1
| | | | | | | In shared libraries the plugin can see non-weak declarations that are still undefined. llvm-svn: 226031
* Fix handling of extern_weak. This was broken by r225983.Rafael Espindola2015-01-141-2/+4
| | | | llvm-svn: 226026
* Handle a symbol being undefined.Rafael Espindola2015-01-141-1/+5
| | | | | | | | | | | | | This can happen if: * It is present in a comdat in one file. * It is not present in the comdat of the file that is kept. * Is is not used. This should fix the LTO boostrap. Thanks to Takumi NAKAMURA for setting up the bot! llvm-svn: 225983
* [cleanup] Re-sort all the #include lines in LLVM usingChandler Carruth2015-01-1419-34/+31
| | | | | | | | | | | utils/sort_includes.py. I clearly haven't done this in a while, so more changed than usual. This even uncovered a missing include from the InstrProf library that I've added. No functionality changed here, just mechanical cleanup of the include order. llvm-svn: 225974
* [PM] Port domtree to the new pass manager (at last).Chandler Carruth2015-01-143-0/+5
| | | | | | | | | | | | This adds the domtree analysis to the new pass manager. The analysis returns the same DominatorTree result entity used by the old pass manager and essentially all of the code is shared. We just have different boilerplate for running and printing the analysis. I've converted one test to run in both modes just to make sure this is exercised while both are live in the tree. llvm-svn: 225969
* [PM] Push the debug option for the new pass manager into the opt toolChandler Carruth2015-01-133-29/+40
| | | | | | | | | | and expose the necessary hooks in the API directly. This makes it much cleaner for example to log the usage of a pass manager from a library. It also makes it more obvious that this functionality isn't "optional" or "asserts-only" for the pass manager. llvm-svn: 225841
* [PM] Fold all three analysis managers into a single AnalysisManagerChandler Carruth2015-01-131-4/+2
| | | | | | | | | | | | | | | | | | | | | | | | | template. This consolidates three copies of nearly the same core logic. It adds "complexity" to the ModuleAnalysisManager in that it makes it possible to share a ModuleAnalysisManager across multiple modules... But it does so by deleting *all of the code*, so I'm OK with that. This will naturally make fixing bugs in this code much simpler, etc. The only down side here is that we have to use 'typename' and 'this->' in various places, and the implementation is lifted into the header. I'll take that for the code size reduction. The convenient names are still typedef-ed and used throughout so that users can largely ignore this aspect of the implementation. The follow-up change to this will do the exact same refactoring for the PassManagers. =D It turns out that the interesting different code is almost entirely in the adaptors. At the end, that should be essentially all that is left. llvm-svn: 225757
* Use the DiagnosticHandler to print diagnostics when reading bitcode.Rafael Espindola2015-01-102-21/+37
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The bitcode reading interface used std::error_code to report an error to the callers and it is the callers job to print diagnostics. This is not ideal for error handling or diagnostic reporting: * For error handling, all that the callers care about is 3 possibilities: * It worked * The bitcode file is corrupted/invalid. * The file is not bitcode at all. * For diagnostic, it is user friendly to include far more information about the invalid case so the user can find out what is wrong with the bitcode file. This comes up, for example, when a developer introduces a bug while extending the format. The compromise we had was to have a lot of error codes. With this patch we use the DiagnosticHandler to communicate with the human and std::error_code to communicate with the caller. This allows us to have far fewer error codes and adds the infrastructure to print better diagnostics. This is so because the diagnostics are printed when he issue is found. The code that detected the problem in alive in the stack and can pass down as much context as needed. As an example the patch updates test/Bitcode/invalid.ll. Using a DiagnosticHandler also moves the fatal/non-fatal error decision to the caller. A simple one like llvm-dis can just use fatal errors. The gold plugin needs a bit more complex treatment because of being passed non-bitcode files. An hypothetical interactive tool would make all bitcode errors non-fatal. llvm-svn: 225562
* Fix an ASAN failure introduced with r225537 (adding the -universal-headers ↵Kevin Enderby2015-01-091-5/+5
| | | | | | | | to llvm-obdump). And a fly by fix to some formatting issues with the same commit. llvm-svn: 225550
* Add the option, -universal-headers, used with -macho to print the Mach-O ↵Kevin Enderby2015-01-093-13/+207
| | | | | | universal headers to llvm-objdump. llvm-svn: 225537
* Revert "Bitcode: Move the DEBUG_LOC record to DEBUG_LOC_OLD"Duncan P. N. Exon Smith2015-01-091-1/+1
| | | | | | | | | | | | | | | This reverts commit r225498 (but leaves r225499, which was a worthy cleanup). My plan was to change `DEBUG_LOC` to store the `MDNode` directly rather than its operands (patch was to go out this morning), but on reflection it's not clear that it's strictly better. (I had missed that the current code is unlikely to emit the `MDNode` at all.) Conflicts: lib/Bitcode/Reader/BitcodeReader.cpp (due to r225499) llvm-svn: 225531
* Bitcode: Move the DEBUG_LOC record to DEBUG_LOC_OLDDuncan P. N. Exon Smith2015-01-091-1/+1
| | | | | | Prepare to simplify the `DebugLoc` record. llvm-svn: 225498
* Run clang-format on tools/llvm-objdump/MachODump.cpp again as some of myKevin Enderby2015-01-081-27/+28
| | | | | | previous changes got in with incorrect formatting. No functional change. llvm-svn: 225417
* Fix uninitialized memory read in llvm-dsymutil for the second time.Alexey Samsonov2015-01-071-1/+2
| | | | | | | This was already fixed by r224481, but apparently was accidentally reverted in r225207. llvm-svn: 225386
* Slightly refactor things for llvm-objdump and the -macho option so it can be ↵Kevin Enderby2015-01-073-47/+98
| | | | | | | | | | | | used with options other than just -disassemble so that universal files can be used with other options combined with -arch options. No functional change to existing options and use. One test case added for the additional functionality with a universal file an a -arch option. llvm-svn: 225383
* Manually specify the folder that llvm-ranlib should reside in for ↵Aaron Ballman2015-01-071-0/+2
| | | | | | CMake-produced solutions that care about such things (like MSVC). This takes llvm-ranlib out of the root solution folder and places it into the Tools folder where it belongs. llvm-svn: 225353
* [PM] Give slightly less horrible names to the utility pass templates forChandler Carruth2015-01-071-6/+6
| | | | | | | | requiring and invalidating specific analyses. Also make their printed names match their class names. Writing these out as prose really doesn't make sense to me any more. llvm-svn: 225346
* Don't loop endlessly for MachO files with 0 ncmdsFilipe Cabecinhas2015-01-061-0/+2
| | | | llvm-svn: 225271
* [PM] Hide a function we only use in an assert behind NDEBUG.Chandler Carruth2015-01-061-0/+2
| | | | llvm-svn: 225258
* [PM] Introduce a utility pass that preserves no analyses.Chandler Carruth2015-01-061-0/+3
| | | | | | | | | Use this to test that path of invalidation. This test actually shows redundant invalidation here that is really bad. I'm going to work on fixing that next, but wanted to commit the test harness now that its all working. llvm-svn: 225257
* [PM] Simplify how we parse the outer layer of the pass pipeline text andChandler Carruth2015-01-061-25/+14
| | | | | | | | | | | | | | remove an extra, redundant pass manager wrapping every run. I had kept seeing these when manually testing, but it was getting really annoying and was going to cause problems with overly eager invalidation. The root cause was an overly complex and unnecessary pile of code for parsing the outer layer of the pass pipeline. We can instead delegate most of this to the recursive pipeline parsing. I've added some somewhat more basic and precise tests to catch this. llvm-svn: 225253
* [PM] Add a utility pass template that synthesizes the invalidation ofChandler Carruth2015-01-061-3/+15
| | | | | | | | | | | | | | | | | | | | | | | | | | | a specific analysis result. This is quite handy to test things, and will also likely be very useful for debugging issues. You could narrow down pass validation failures by walking these invalidate pass runs up and down the pass pipeline, etc. I've added support to the pass pipeline parsing to be able to create one of these for any analysis pass desired. Just adding this class uncovered one latent bug where the AnalysisManager CRTP base class had a hard-coded Module type rather than using IRUnitT. I've also added tests for invalidation and caching of analyses in a basic way across all the pass managers. These in turn uncovered two more bugs where we failed to correctly invalidate an analysis -- its results were invalidated but the key for re-running the pass was never cleared and so it was never re-run. Quite nasty. I'm very glad to debug this here rather than with a full system. Also, yes, the naming here is horrid. I'm going to update some of the names to be slightly less awful shortly. But really, I've no "good" ideas for naming. I'll be satisfied if I can get it to "not bad". llvm-svn: 225246
* [PM] Simplify how we use the registry by including it only once. StillChandler Carruth2015-01-061-18/+0
| | | | | | | | | more verbose than I'd like, but the code really isn't that interesting, and this still seems vastly simpler than any other solutions I've come up with. =] Maybe if we get to the 10th IR unit, this will be a problem in practice. llvm-svn: 225245
OpenPOWER on IntegriCloud