summaryrefslogtreecommitdiff
path: root/tools
Commit message (Collapse)AuthorAge
...
* Remove unused include following r199929Alp Toker2014-01-23
| | | | git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@199930 91177308-0d34-0410-b5e6-96231b3b80d8
* Replace the interim lli build fix with something cleanerAlp Toker2014-01-23
| | | | | | | | | | Eliminates the LLI_BUILDING_CHILD build hack from r199885. Also add a FIXME to remove code that tricks the tests into passing when the feature fails to work. Please don't do stuff like this, the tests exist for a reason! git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@199929 91177308-0d34-0410-b5e6-96231b3b80d8
* Add target analysis passes to the codegen pipeline for MCJIT.Juergen Ributzka2014-01-23
| | | | | | | | | | | This patch adds the target analysis passes (usually TargetTransformInfo) to the codgen pipeline. We also expose now the AddAnalysisPasses method through the C API, because the optimizer passes would also benefit from better target-specific cost models. Reviewed by Andrew Kaylor git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@199926 91177308-0d34-0410-b5e6-96231b3b80d8
* Windows/ChildTarget.inc: LLIChildTarget::allocate() has gone since r199881.NAKAMURA Takumi2014-01-23
| | | | git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@199889 91177308-0d34-0410-b5e6-96231b3b80d8
* Interim build fix for MakefilesAlp Toker2014-01-23
| | | | | | Looks like some parts still need detangling. Let's see if this holds for now. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@199885 91177308-0d34-0410-b5e6-96231b3b80d8
* Prospective Makefile build fixAlp Toker2014-01-23
| | | | git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@199882 91177308-0d34-0410-b5e6-96231b3b80d8
* Refactor lli-child-target to remove duplicated codeAlp Toker2014-01-23
| | | | | | | | | | | | | | Eliminate the copies LLVM's System mmap and cache invalidation code. These were slowly drifting away from the original version, and moreover the copied code was a dead end in terms of portability. We now statically link to Support but in practice with stripping this adds next to no weight to the resultant binary. Also avoid installing lli-child-target to the user's $PATH. It's not meant to be run directly. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@199881 91177308-0d34-0410-b5e6-96231b3b80d8
* Tweak r199835 to use can_execute() instead of exists()Alp Toker2014-01-22
| | | | | | | The execution code path crashes if it can't execute the binary so we might as well take precautions here. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@199844 91177308-0d34-0410-b5e6-96231b3b80d8
* Eliminate inappropriate use of FindProgramByName() from lliAlp Toker2014-01-22
| | | | git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@199835 91177308-0d34-0410-b5e6-96231b3b80d8
* Don't open or fstat files twice in llvm-ar.Rafael Espindola2014-01-22
| | | | | | We still read/mmap them twice, but the fix for that is a bit more complex. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@199815 91177308-0d34-0410-b5e6-96231b3b80d8
* Pass the computed magic to createBinary and createObjectFile if available.Rafael Espindola2014-01-22
| | | | | | | identify_magic is not free, so we should avoid calling it twice. The argument also makes it cheap for createBinary to just forward to createObjectFile. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@199813 91177308-0d34-0410-b5e6-96231b3b80d8
* Whitespace.NAKAMURA Takumi2014-01-22
| | | | git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@199785 91177308-0d34-0410-b5e6-96231b3b80d8
* Change createObjectFile to return an ErrorOr.Rafael Espindola2014-01-22
| | | | git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@199776 91177308-0d34-0410-b5e6-96231b3b80d8
* Be a bit more consistent about using ErrorOr when constructing Binary objects.Rafael Espindola2014-01-21
| | | | | | | | | | | | | | | | | | | | | | | The constructors of classes deriving from Binary normally take an error_code as an argument to the constructor. My original intent was to change them to have a trivial constructor and move the initial parsing logic to a static method returning an ErrorOr. I changed my mind because: * A constructor with an error_code out parameter is extremely convenient from the implementation side. We can incrementally construct the object and give up when we find an error. * It is very efficient when constructing on the stack or when there is no error. The only inefficient case is where heap allocating and an error is found (we have to free the memory). The result is that this is a much smaller patch. It just standardizes the create* helpers to return an ErrorOr. Almost no functionality change: The only difference is that this found that we were trying to read past the end of COFF import library but ignoring the error. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@199770 91177308-0d34-0410-b5e6-96231b3b80d8
* Adding new LTO APIs to parse metadata nodes and extract linker options andYunzhong Gao2014-01-21
| | | | | | | | | | dependent libraries from a bitcode module. Differential Revision: http://llvm-reviews.chandlerc.com/D2343 git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@199759 91177308-0d34-0410-b5e6-96231b3b80d8
* Rename these methods to match the style guide.Rafael Espindola2014-01-21
| | | | git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@199751 91177308-0d34-0410-b5e6-96231b3b80d8
* tools: use 64-bit print specifierSaleem Abdulrasool2014-01-21
| | | | | | | Try to repair the ARM Cortex-A15 buildbot by using a more appropriate conversion specifier. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@199711 91177308-0d34-0410-b5e6-96231b3b80d8
* tools: support decoding ARM EHABI opcodes in readobjSaleem Abdulrasool2014-01-21
| | | | | | | | | | | | | | Add support to llvm-readobj to decode the actual opcodes. The ARM EHABI opcodes are a variable length instruction set that describe the operations required for properly unwinding stack frames. The primary motivation for this change is to ease the creation of tests for the ARM EHABI object emission as well as the unwinding directive handling in the ARM IAS. Thanks to Logan Chien for an extra test case! git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@199708 91177308-0d34-0410-b5e6-96231b3b80d8
* Whitespace.NAKAMURA Takumi2014-01-20
| | | | git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@199667 91177308-0d34-0410-b5e6-96231b3b80d8
* [PM] Wire up the Verifier for the new pass manager and connect it to theChandler Carruth2014-01-20
| | | | | | | | | | | | | | | | | | | | | | various opt verifier commandline options. Mostly mechanical wiring of the verifier to the new pass manager. Exercises one of the more unusual aspects of it -- a pass can be either a module or function pass interchangably. If this is ever problematic, we can make things more constrained, but for things like the verifier where there is an "obvious" applicability at both levels, it seems convenient. This is the next-to-last piece of basic functionality left to make the opt commandline driving of the new pass manager minimally functional for testing and further development. There is still a lot to be done there (notably the factoring into .def files to kill the current boilerplate code) but it is relatively uninteresting. The only interesting bit left for minimal functionality is supporting the registration of analyses. I'm planning on doing that on top of the .def file switch mostly because the boilerplate for the analyses would be significantly worse. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@199646 91177308-0d34-0410-b5e6-96231b3b80d8
* [PM] Make the verifier work independently of any pass manager.Chandler Carruth2014-01-19
| | | | | | | | | | | | | | | | | | | | | | | This makes the 'verifyFunction' and 'verifyModule' functions totally independent operations on the LLVM IR. It also cleans up their API a bit by lifting the abort behavior into their clients and just using an optional raw_ostream parameter to control printing. The implementation of the verifier is now just an InstVisitor with no multiple inheritance. It also is significantly more const-correct, and hides the const violations internally. The two layers that force us to break const correctness are building a DomTree and dispatching through the InstVisitor. A new VerifierPass is used to implement the legacy pass manager interface in terms of the other pieces. The error messages produced may be slightly different now, and we may have slightly different short circuiting behavior with different usage models of the verifier, but generally everything works equivalently and this unblocks wiring the verifier up to the new pass manager. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@199569 91177308-0d34-0410-b5e6-96231b3b80d8
* llvm-objdump/COFF: Print ordinal base number.Rui Ueyama2014-01-17
| | | | git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@199518 91177308-0d34-0410-b5e6-96231b3b80d8
* [opt][PassInfo] Allow opt to run passes that need target machine.Quentin Colombet2014-01-16
| | | | | | | | | | | | | | | | | | | When registering a pass, a pass can now specify a second construct that takes as argument a pointer to TargetMachine. The PassInfo class has been updated to reflect that possibility. If such a constructor exists opt will use it instead of the default constructor when instantiating the pass. Since such IR passes are supposed to be rare, no specific support has been added to this commit to allow an easy registration of such a pass. In other words, for such pass, the initialization function has to be hand-written (see CodeGenPrepare for instance). Now, codegenprepare can be tested using opt: opt -codegenprepare -mtriple=mytriple input.ll git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@199430 91177308-0d34-0410-b5e6-96231b3b80d8
* Fix style issues.Rui Ueyama2014-01-16
| | | | git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@199423 91177308-0d34-0410-b5e6-96231b3b80d8
* llvm-objdump/COFF: Print DLL name in the export table header.Rui Ueyama2014-01-16
| | | | git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@199422 91177308-0d34-0410-b5e6-96231b3b80d8
* llvm-symbolizer: make mangled name heuristic apply to all symbolsEd Maste2014-01-16
| | | | | | | | PR: http://llvm.org/pr18431 Review: http://llvm-reviews.chandlerc.com/D2552 git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@199404 91177308-0d34-0410-b5e6-96231b3b80d8
* Revert r199361: Now, the sanitizer got the changeQuentin Colombet2014-01-16
| | | | git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@199362 91177308-0d34-0410-b5e6-96231b3b80d8
* [LTO] Modify lto.exports to force the sanitizer to rebuilt LTO.exportsQuentin Colombet2014-01-16
| | | | git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@199361 91177308-0d34-0410-b5e6-96231b3b80d8
* llmv-objdump/COFF: Print export table contents.Rui Ueyama2014-01-16
| | | | | | | | | | | | | | | | This patch adds the capability to dump export table contents. An example output is this: Export Table: Ordinal RVA Name 5 0x2008 exportfn1 6 0x2010 exportfn2 By adding this feature to llvm-objdump, we will be able to use it to check export table contents in LLD's tests. Currently we are doing binary comparison in the tests, which is fragile and not readable to humans. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@199358 91177308-0d34-0410-b5e6-96231b3b80d8
* llvm-objdump: Don't print "Import table:" header if there's no import table.Rui Ueyama2014-01-15
| | | | | | | | If a binary does not depend on any DLL, it does not contain import table at all. Printing the section title without contents looks wrong, so we shouldn't print it in that case. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@199340 91177308-0d34-0410-b5e6-96231b3b80d8
* [LTO] Add a hook to map LLVM diagnostics into the clients of LTO.Quentin Colombet2014-01-15
| | | | | | | | | | | | | | | | | | | | Add a hook in the C API of LTO so that clients of the code generator can set their own handler for the LLVM diagnostics. The handler is defined like this: typedef void (*lto_diagnostic_handler_t)(lto_codegen_diagnostic_severity_t severity, const char *diag, void *ctxt) - severity says how bad this is. - diag is a string that contains the diagnostic message. - ctxt is the registered context for this handler. This hook is more general than the lto_get_error_message, since this function keeps only the latest message and can only be queried when something went wrong (no warning for instance). <rdar://problem/15517596> git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@199338 91177308-0d34-0410-b5e6-96231b3b80d8
* Return an ErrorOr<Binary *> from createBinary.Rafael Espindola2014-01-15
| | | | | | | | I did write a version returning ErrorOr<OwningPtr<Binary> >, but it is too cumbersome to use without std::move. I will keep the patch locally and submit when we switch to c++11. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@199326 91177308-0d34-0410-b5e6-96231b3b80d8
* Whitespace.NAKAMURA Takumi2014-01-15
| | | | git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@199305 91177308-0d34-0410-b5e6-96231b3b80d8
* Check the error code and save a call to sys::fs::exists.Rafael Espindola2014-01-15
| | | | git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@199293 91177308-0d34-0410-b5e6-96231b3b80d8
* Make parseBitcodeFile return an ErrorOr<Module *>.Rafael Espindola2014-01-15
| | | | git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@199279 91177308-0d34-0410-b5e6-96231b3b80d8
* Return an error_code from materializeAllPermanently.Rafael Espindola2014-01-14
| | | | git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@199275 91177308-0d34-0410-b5e6-96231b3b80d8
* Fix Remote MCJIT on WindowsRenato Golin2014-01-14
| | | | git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@199268 91177308-0d34-0410-b5e6-96231b3b80d8
* Sanitize MCJIT remote executionRenato Golin2014-01-14
| | | | | | | | | | | | MCJIT remote execution (ChildTarget+RemoteTargetExternal) protocol was in dire need of refactoring. It was fail-prone, had no error reporting and implemented the same message logic on every single function. This patch rectifies it, and makes it work on ARM, where it was randomly failing. Other architectures shall profit from this change as well, making their buildbots and releases more reliable. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@199261 91177308-0d34-0410-b5e6-96231b3b80d8
* Reapply "LTO: add API to set strategy for -internalize"Duncan P. N. Exon Smith2014-01-14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Reapply r199191, reverted in r199197 because it carelessly broke Other/link-opts.ll. The problem was that calling createInternalizePass("main") would select createInternalizePass(bool("main")) instead of createInternalizePass(ArrayRef<const char *>("main")). This commit fixes the bug. The original commit message follows. Add API to LTOCodeGenerator to specify a strategy for the -internalize pass. This is a new attempt at Bill's change in r185882, which he reverted in r188029 due to problems with the gold linker. This puts the onus on the linker to decide whether (and what) to internalize. In particular, running internalize before outputting an object file may change a 'weak' symbol into an internal one, even though that symbol could be needed by an external object file --- e.g., with arclite. This patch enables three strategies: - LTO_INTERNALIZE_FULL: the default (and the old behaviour). - LTO_INTERNALIZE_NONE: skip -internalize. - LTO_INTERNALIZE_HIDDEN: only -internalize symbols with hidden visibility. LTO_INTERNALIZE_FULL should be used when linking an executable. Outputting an object file (e.g., via ld -r) is more complicated, and depends on whether hidden symbols should be internalized. E.g., for ld -r, LTO_INTERNALIZE_NONE can be used when -keep_private_externs, and LTO_INTERNALIZE_HIDDEN can be used otherwise. However, LTO_INTERNALIZE_FULL is inappropriate, since the output object file will eventually need to link with others. lto_codegen_set_internalize_strategy() sets the strategy for subsequent calls to lto_codegen_write_merged_modules() and lto_codegen_compile*(). <rdar://problem/14334895> git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@199244 91177308-0d34-0410-b5e6-96231b3b80d8
* Handle UIDs and GIDs that don't fit in 6 decimal places.Rafael Espindola2014-01-14
| | | | | | | | Newer unix systems have 32 bit uid and gid types, but the archive format was not updated. Fortunately, these fields are not normally used. Just truncate the data to fit in 6 chars. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@199223 91177308-0d34-0410-b5e6-96231b3b80d8
* Revert r199191, "LTO: add API to set strategy for -internalize"NAKAMURA Takumi2014-01-14
| | | | | | Please update also Other/link-opts.ll, in next time. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@199197 91177308-0d34-0410-b5e6-96231b3b80d8
* LTO: add API to set strategy for -internalizeDuncan P. N. Exon Smith2014-01-14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Add API to LTOCodeGenerator to specify a strategy for the -internalize pass. This is a new attempt at Bill's change in r185882, which he reverted in r188029 due to problems with the gold linker. This puts the onus on the linker to decide whether (and what) to internalize. In particular, running internalize before outputting an object file may change a 'weak' symbol into an internal one, even though that symbol could be needed by an external object file --- e.g., with arclite. This patch enables three strategies: - LTO_INTERNALIZE_FULL: the default (and the old behaviour). - LTO_INTERNALIZE_NONE: skip -internalize. - LTO_INTERNALIZE_HIDDEN: only -internalize symbols with hidden visibility. LTO_INTERNALIZE_FULL should be used when linking an executable. Outputting an object file (e.g., via ld -r) is more complicated, and depends on whether hidden symbols should be internalized. E.g., for ld -r, LTO_INTERNALIZE_NONE can be used when -keep_private_externs, and LTO_INTERNALIZE_HIDDEN can be used otherwise. However, LTO_INTERNALIZE_FULL is inappropriate, since the output object file will eventually need to link with others. lto_codegen_set_internalize_strategy() sets the strategy for subsequent calls to lto_codegen_write_merged_modules() and lto_codegen_compile*(). <rdar://problem/14334895> git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@199191 91177308-0d34-0410-b5e6-96231b3b80d8
* [PM] Split DominatorTree into a concrete analysis result object whichChandler Carruth2014-01-13
| | | | | | | | | | | | | | | | | | | | | | | can be used by both the new pass manager and the old. This removes it from any of the virtual mess of the pass interfaces and lets it derive cleanly from the DominatorTreeBase<> template. In turn, tons of boilerplate interface can be nuked and it turns into a very straightforward extension of the base DominatorTree interface. The old analysis pass is now a simple wrapper. The names and style of this split should match the split between CallGraph and CallGraphWrapperPass. All of the users of DominatorTree have been updated to match using many of the same tricks as with CallGraph. The goal is that the common type remains the resulting DominatorTree rather than the pass. This will make subsequent work toward the new pass manager significantly easier. Also in numerous places things became cleaner because I switched from re-running the pass (!!! mid way through some other passes run!!!) to directly recomputing the domtree. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@199104 91177308-0d34-0410-b5e6-96231b3b80d8
* [cleanup] Move the Dominators.h and Verifier.h headers into the IRChandler Carruth2014-01-13
| | | | | | | | | | | | | | | | | | directory. These passes are already defined in the IR library, and it doesn't make any sense to have the headers in Analysis. Long term, I think there is going to be a much better way to divide these matters. The dominators code should be fully separated into the abstract graph algorithm and have that put in Support where it becomes obvious that evn Clang's CFGBlock's can use it. Then the verifier can manually construct dominance information from the Support-driven interface while the Analysis library can provide a pass which both caches, reconstructs, and supports a nice update API. But those are very long term, and so I don't want to leave the really confusing structure until that day arrives. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@199082 91177308-0d34-0410-b5e6-96231b3b80d8
* [cleanup] Add a missing include exposed by resorting other includes.Chandler Carruth2014-01-13
| | | | | | Should fix the build. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@199081 91177308-0d34-0410-b5e6-96231b3b80d8
* Re-sort #include lines again, prior to moving headers around.Chandler Carruth2014-01-13
| | | | git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@199080 91177308-0d34-0410-b5e6-96231b3b80d8
* [PM] Wire up support for writing bitcode with new PM.Chandler Carruth2014-01-13
| | | | | | | | | | This moves the old pass creation functionality to its own header and updates the callers of that routine. Then it adds a new PM supporting bitcode writer to the header file, and wires that up in the opt tool. A test is added that round-trips code into bitcode and back out using the new pass manager. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@199078 91177308-0d34-0410-b5e6-96231b3b80d8
* [PM] Wire up support for printing assembly output from the opt command.Chandler Carruth2014-01-13
| | | | | | This lets us round-trip IR in the expected manner with the opt tool. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@199075 91177308-0d34-0410-b5e6-96231b3b80d8
* [PM] Add an enum for describing the desired output strategy, and runChandler Carruth2014-01-13
| | | | | | | | that through the interface rather than a simple bool. This should allow starting to wire up real output to round-trip IR through opt with the new pass manager. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@199071 91177308-0d34-0410-b5e6-96231b3b80d8
* [PM] Add module and function printing passes for the new pass manager.Chandler Carruth2014-01-12
| | | | | | | | | This implements the legacy passes in terms of the new ones. It adds basic testing using explicit runs of the passes. Next up will be wiring the basic output mechanism of opt up when the new pass manager is engaged unless bitcode writing is requested. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@199049 91177308-0d34-0410-b5e6-96231b3b80d8