summaryrefslogtreecommitdiffstats
path: root/llvm/tools
Commit message (Collapse)AuthorAgeFilesLines
...
* [llvm-pdbdump] [yaml2pdb] always include object file name in module infoBob Haarman2017-05-251-1/+1
| | | | | | | | | | | | | | | | | | | | | | | Summary: Previously, the yaml2pdb subcommand of llvm-pdbdump only included object file names in module info if a module info stream was present. This change makes it so that we include the object file name even if there is no module info stream for the module. As a result, running llvm-pdbdump pdb2yaml -dbi-module-info original.pdb > original.yaml && llvm-pdbdump yaml2pdb -pdb=new.pdb original.yaml && llvm-pdbdump pdb2yaml -dbi-module-info new.pdb > new.yaml now produces identical original.yaml and new.yaml files. Reviewers: amccarth, zturner Reviewed By: zturner Subscribers: fhahn, llvm-commits Differential Revision: https://reviews.llvm.org/D33463 llvm-svn: 303891
* Print symbols from COFF import libraries.Rafael Espindola2017-05-241-1/+16
| | | | | | | | | This change allows llvm-nm to print symbols found in import libraries, in part by allowing COFFImportFiles to be casted to SymbolicFiles. Patch by Dave Lee! llvm-svn: 303821
* Fix a couple of typos in memory intrinsic optimization output (NFC)Teresa Johnson2017-05-241-1/+1
| | | | | | s/instrinsic/intrinsic llvm-svn: 303782
* Fix broken build.Zachary Turner2017-05-242-4/+3
| | | | llvm-svn: 303711
* [PDB] Hash types up front when merging types instead of using StringMapReid Kleckner2017-05-231-8/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: First, StringMap uses llvm::HashString, which is only good for short identifiers and really bad for large blobs of binary data like type records. Moving to `DenseMap<StringRef, TypeIndex>` with some tricks for memory allocation fixes that. Unfortunately, that didn't buy very much performance. Profiling showed that we spend a long time during DenseMap growth rehashing existing entries. Also, in general, DenseMap is faster when the keys are small. This change takes that to the logical conclusion by introducing a small wrapper value type around a pointer to key data. The key data contains a precomputed hash, the original record data (pointer and size), and the type index, which is the "value" of our original map. This reduces the time to produce llvm-as.exe and llvm-as.pdb from ~15s on my machine to 3.5s, which is about a 4x improvement. Reviewers: zturner, inglorion, ruiu Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D33428 llvm-svn: 303665
* Revert "Make TypeSerializer's StringMap use the same allocator."Zachary Turner2017-05-231-2/+2
| | | | | | | | This reverts commit e34ccb7b57da25cc89ded913d8638a2906d1110a. This is causing failures on the ASAN bots. llvm-svn: 303640
* Infer relocation model from module flags in relocatable LTO link.Evgeniy Stepanov2017-05-221-2/+4
| | | | | | Fix for PR33096. llvm-svn: 303578
* Implement various flavors of type merging.Zachary Turner2017-05-222-11/+12
| | | | | | | | | | | | | | Previous algotirhm assumed that types and ids are in a single unified stream. For inputs that come from object files, this is the case. But if the input is already a PDB, or is the result of a previous merge, then the types and ids will already have been split up, in which case we need an algorithm that can accept operate on independent streams of types and ids that refer across stream boundaries to each other. Differential Revision: https://reviews.llvm.org/D33417 llvm-svn: 303577
* Make TypeSerializer's StringMap use the same allocator.Zachary Turner2017-05-221-2/+2
| | | | llvm-svn: 303576
* Add functionality to cvtres to parse all entries in res file.Eric Beckmann2017-05-203-3/+106
| | | | | | | | | | | Summary: Added the new modules in the Object/ folder. Updated the llvm-cvtres interface as well, and added additional tests. Subscribers: llvm-commits, mgorny Differential Revision: https://reviews.llvm.org/D33180 llvm-svn: 303480
* Resubmit "[CodeView] Provide a common interface for type collections."Zachary Turner2017-05-1910-117/+96
| | | | | | | | | | | | This was originally reverted because it was a breaking a bunch of bots and the breakage was not surfacing on Windows. After much head-scratching this was ultimately traced back to a bug in the lit test runner related to its pipe handling. Now that the bug in lit is fixed, Windows correctly reports these test failures, and as such I have finally (hopefully) fixed all of them in this patch. llvm-svn: 303446
* Rewrite llvm-lto's codegen() using ThinCodeGenerator::run(). NFC-ish.Adrian Prantl2017-05-191-9/+15
| | | | | | Differential Revision: https://reviews.llvm.org/D33360 llvm-svn: 303437
* Fix compilation failure.Zachary Turner2017-05-191-1/+1
| | | | llvm-svn: 303410
* Revert "[CodeView] Provide a common interface for type collections."Zachary Turner2017-05-1910-97/+119
| | | | | | | | | | | | | | | | | | This is a squash of ~5 reverts of, well, pretty much everything I did today. Something is seriously broken with lit on Windows right now, and as a result assertions that fire in tests are triggering failures. I've been breaking non-Windows bots all day which has seriously confused me because all my tests have been passing, and after running lit with -a to view the output even on successful runs, I find out that the tool is crashing and yet lit is still reporting it as a success! At this point I don't even know where to start, so rather than leave the tree broken for who knows how long, I will get this back to green, and then once lit is fixed on Windows, hopefully hopefully fix the remaining set of problems for real. llvm-svn: 303409
* Fix some build errors and warnings.Zachary Turner2017-05-182-2/+2
| | | | llvm-svn: 303391
* [CodeView] Raise the source to ID map out of the TypeStreamMerger.Zachary Turner2017-05-182-6/+11
| | | | | | | This map will be needed to rewrite symbol streams after re-writing the corresponding type streams. llvm-svn: 303390
* [llvm-pdbdump] Add the ability to merge PDBs.Zachary Turner2017-05-181-0/+68
| | | | | | | | | | | | | | | Merging PDBs is a feature that will be used heavily by the linker. The functionality already exists but does not have deep test coverage because it's not easily exposed through any tools. This patch aims to address that by adding the ability to merge PDBs via llvm-pdbdump. It takes arbitrarily many PDBs and outputs a single PDB. Using this new functionality, a test is added for merging type records. Future patches will add the ability to merge symbol records, module information, etc. llvm-svn: 303389
* [CodeView] Provide a common interface for type collections.Zachary Turner2017-05-189-119/+96
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Right now we have multiple notions of things that represent collections of types. Most commonly used are TypeDatabase, which is supposed to keep mappings from TypeIndex to type name when reading a type stream, which happens when reading PDBs. And also TypeTableBuilder, which is used to build up a collection of types dynamically which we will later serialize (i.e. when writing PDBs). But often you just want to do some operation on a collection of types, and you may want to do the same operation on any kind of collection. For example, you might want to merge two TypeTableBuilders or you might want to merge two type streams that you loaded from various files. This dichotomy between reading and writing is responsible for a lot of the existing code duplication and overlapping responsibilities in the existing CodeView library classes. For example, after building up a TypeTableBuilder with a bunch of type records, if we want to dump it we have to re-invent a bunch of extra glue because our dumper takes a TypeDatabase or a CVTypeArray, which are both incompatible with TypeTableBuilder. This patch introduces an abstract base class called TypeCollection which is shared between the various type collection like things. Wherever we previously stored a TypeDatabase& in some common class, we now store a TypeCollection&. The advantage of this is that all the details of how the collection are implemented, such as lazy deserialization of partial type streams, is completely transparent and you can just treat any collection of types the same regardless of where it came from. Differential Revision: https://reviews.llvm.org/D33293 llvm-svn: 303388
* [LegacyPassManager] Remove TargetMachine constructorsFrancis Visoiu Mistrih2017-05-182-6/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This provides a new way to access the TargetMachine through TargetPassConfig, as a dependency. The patterns replaced here are: * Passes handling a null TargetMachine call `getAnalysisIfAvailable<TargetPassConfig>`. * Passes not handling a null TargetMachine `addRequired<TargetPassConfig>` and call `getAnalysis<TargetPassConfig>`. * MachineFunctionPasses now use MF.getTarget(). * Remove all the TargetMachine constructors. * Remove INITIALIZE_TM_PASS. This fixes a crash when running `llc -start-before prologepilog`. PEI needs StackProtector, which gets constructed without a TargetMachine by the pass manager. The StackProtector pass doesn't handle the case where there is no TargetMachine, so it segfaults. Related to PR30324. Differential Revision: https://reviews.llvm.org/D33222 llvm-svn: 303360
* [lib/Object] - Minor API update for llvm::Decompressor.George Rimar2017-05-181-1/+1
| | | | | | | | | | | | | | | | | I revisited Decompressor API (issue with it was triggered during D32865 review) and found it is probably provides more then we really need. Issue was about next method's signature: Error decompress(SmallString<32> &Out); It is too strict. At first I wanted to change it to decompress(SmallVectorImpl<char> &Out), but then found it is still not flexible because sticks to SmallVector. During reviews was suggested to use templating to simplify code. Patch do that. Differential revision: https://reviews.llvm.org/D33200 llvm-svn: 303331
* [llvm-pdbdump] in yaml2pdb, generate default output filename if none givenBob Haarman2017-05-171-4/+10
| | | | | | | | | | | | | | | | | | | | Summary: llvm-pdbdump yaml2pdb used to fail with a misleading error message ("An I/O error occurred on the file system") if no output file was specified. This change adds an assert to PDBFileBuilder to check that an output file name is specified, and makes llvm-pdbdump generate an output file name based on the input file name if no output file name is explicitly specified. Reviewers: amccarth, zturner Reviewed By: zturner Subscribers: fhahn, llvm-commits Differential Revision: https://reviews.llvm.org/D33296 llvm-svn: 303299
* [BinaryStream] Reduce the amount of boiler plate needed to use.Zachary Turner2017-05-171-23/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Often you have an array and you just want to use it. With the current design, you have to first construct a `BinaryByteStream`, and then create a `BinaryStreamRef` from it. Worse, the `BinaryStreamRef` holds a pointer to the `BinaryByteStream`, so you can't just create a temporary one to appease the compiler, you have to actually hold onto both the `ArrayRef` as well as the `BinaryByteStream` *AND* the `BinaryStreamReader` on top of that. This makes for very cumbersome code, often requiring one to store a `BinaryByteStream` in a class just to circumvent this. At the cost of some added complexity (not exposed to users, but internal to the library), we can do better than this. This patch allows us to construct `BinaryStreamReaders` and `BinaryStreamWriters` directly from source data (e.g. `StringRef`, `MutableArrayRef<uint8_t>`, etc). Not only does this reduce the amount of code you have to type and make it more obvious how to use it, but it solves real lifetime issues when it's inconvenient to hold onto a `BinaryByteStream` for a long time. The additional complexity is in the form of an added layer of indirection. Whereas before we simply stored a `BinaryStream*` in the ref, we now store both a `BinaryStream*` **and** a `std::shared_ptr<BinaryStream>`. When the user wants to construct a `BinaryStreamRef` directly from an `ArrayRef` etc, we allocate an internal object that holds ownership over a `BinaryByteStream` and forwards all calls, and store this in the `shared_ptr<>`. This also maintains the ref semantics, as you can copy it by value and references refer to the same underlying stream -- the one being held in the object stored in the `shared_ptr`. Differential Revision: https://reviews.llvm.org/D33293 llvm-svn: 303294
* [CodeView] Simplify the use of visiting type records & streams.Zachary Turner2017-05-174-92/+49
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | There is often a lot of boilerplate code required to visit a type record or type stream. The #1 use case is that you have a sequence of bytes that represent one or more records, and you want to deserialize each one, switch on it, and call a callback with the deserialized record that the user can examine. Currently this requires at least 6 lines of code: codeview::TypeVisitorCallbackPipeline Pipeline; Pipeline.addCallbackToPipeline(Deserializer); Pipeline.addCallbackToPipeline(MyCallbacks); codeview::CVTypeVisitor Visitor(Pipeline); consumeError(Visitor.visitTypeRecord(Record)); With this patch, it becomes one line of code: consumeError(codeview::visitTypeRecord(Record, MyCallbacks)); This is done by having the deserialization happen internally inside of the visitTypeRecord function. Since this is occasionally not desirable, the function provides a 3rd parameter that can be used to change this behavior. Hopefully this can significantly reduce the barrier to entry to using the visitation infrastructure. Differential Revision: https://reviews.llvm.org/D33245 llvm-svn: 303271
* [X86] Relocate code of replacement of subtarget unsupported masked memory ↵Ayman Musa2017-05-152-0/+2
| | | | | | | | | | | | | | intrinsics to run also on -O0 option. Currently, when masked load, store, gather or scatter intrinsics are used, we check in CodeGenPrepare pass if the subtarget support these intrinsics, if not we replace them with scalar code - this is a functional transformation not an optimization (not optional). CodeGenPrepare pass does not run when the optimization level is set to CodeGenOpt::None (-O0). Functional transformation should run with all optimization levels, so here I created a new pass which runs on all optimization levels and does no more than this transformation. Differential Revision: https://reviews.llvm.org/D32487 llvm-svn: 303050
* [llvm-pdbdump] Add the option to sort functions and data.Zachary Turner2017-05-144-11/+136
| | | | llvm-svn: 302998
* Move lib/LibDriver -> lib/ToolDrivers/llvm-lib. NFCI.Peter Collingbourne2017-05-131-1/+1
| | | | | | | This reorganisation prevents us from cluttering up the top-level lib directory with more driver libraries such as llvm-dlltool (see D29892). llvm-svn: 302995
* [CodeView] Add a random access type visitor.Zachary Turner2017-05-121-1/+1
| | | | | | | | | | | | This adds a visitor that is capable of accessing type records randomly and caching intermediate results that it learns about during partial linear scans. This yields amortized O(1) access to a type stream even though type streams cannot normally be indexed. Differential Revision: https://reviews.llvm.org/D33009 llvm-svn: 302936
* [llvm-readobj] Improve errors on invalid binarySam Clegg2017-05-101-18/+3
| | | | | | | | | | | | | | The previous code was discarding the error message from createBinary() by calling errorToErrorCode(). This meant that such error were always reported unhelpfully as "Invalid data was encountered while parsing the file". Other tools such as llvm-objdump already produce a more the error message in this case. Differential Revision: https://reviews.llvm.org/D32985 llvm-svn: 302664
* Add a late IR expansion pass for the experimental reduction intrinsics.Amara Emerson2017-05-102-0/+2
| | | | | | | | | This pass uses a new target hook to decide whether or not to expand a particular intrinsic to the shuffevector sequence. Differential Revision: https://reviews.llvm.org/D32245 llvm-svn: 302631
* [CodeGen] Split SafeStack into a LegacyPass and a utility. NFC.Ahmed Bougacha2017-05-101-1/+1
| | | | | | | | | This lets the pass focus on gathering the required analyzes, and the utility class focus on the transformation. Differential Revision: https://reviews.llvm.org/D31303 llvm-svn: 302609
* [WebAssembly] Fix build error in wasm YAML codeSam Clegg2017-05-102-7/+7
| | | | | | | | | | | This warning didn't show up on my local build but is causing the bots to fail. Seems like a bad idea to have types and variables with the same name anyhow. Differential Revision: https://reviews.llvm.org/D33022 llvm-svn: 302606
* [WebAssembly] Improve libObject support for wasm imports and exportsSam Clegg2017-05-092-25/+49
| | | | | | | | | | | | Previously we had only supported the importing and exporting of functions and globals. Also, add usefull overload of getWasmSymbol() and getNumberOfSymbols() in support of lld port. Differential Revision: https://reviews.llvm.org/D33011 llvm-svn: 302601
* [ExecutionEngine] Make RuntimeDyld::MemoryManager responsible for tracking EHLang Hames2017-05-092-5/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | frames. RuntimeDyld was previously responsible for tracking allocated EH frames, but it makes more sense to have the RuntimeDyld::MemoryManager track them (since the frames are allocated through the memory manager, and written to memory owned by the memory manager). This patch moves the frame tracking into RTDyldMemoryManager, and changes the deregisterFrames method on RuntimeDyld::MemoryManager from: void deregisterEHFrames(uint8_t *Addr, uint64_t LoadAddr, size_t Size); to: void deregisterEHFrames(); Separating this responsibility will allow ORC to continue to throw the RuntimeDyld instances away post-link (saving a few dozen bytes per lazy function) while properly deregistering frames when modules are unloaded. This patch also updates ORC to call deregisterEHFrames when modules are unloaded. This fixes a bug where an exception that tears down the JIT can then unwind through dangling EH frames that have been deallocated but not deregistered, resulting in UB. For people using SectionMemoryManager this should be pretty much a no-op. For people with custom allocators that override registerEHFrames/deregisterEHFrames, you will now be responsible for tracking allocated EH frames. Reviewed in https://reviews.llvm.org/D32829 llvm-svn: 302589
* Fix the Endianness bug by adding the little endian UTF marker.Eric Beckmann2017-05-091-0/+8
| | | | | | | | | | | | Summary: Quick fix Reviewers: zturner, uweigand Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D33014 llvm-svn: 302573
* Suppress all uses of LLVM_END_WITH_NULL. NFC.Serge Guelton2017-05-091-2/+1
| | | | | | | | | Use variadic templates instead of relying on <cstdarg> + sentinel. This enforces better type checking and makes code more readable. Differential Revision: https://reviews.llvm.org/D32541 llvm-svn: 302571
* Hopefully one last commit to fix this patch, addresses string referenceEric Beckmann2017-05-081-3/+7
| | | | | | issues. llvm-svn: 302401
* Update llvm-readobj -coff-resources to display tree structure.Eric Beckmann2017-05-081-8/+93
| | | | | | | | | | | | Summary: Continue making updates to llvm-readobj to display resource sections. This is necessary for testing the up and coming cvtres tool. Reviewers: zturner Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D32609 llvm-svn: 302399
* Revert "Hopefully one last commit to fix this patch, addresses string reference"Eric Beckmann2017-05-081-97/+8
| | | | | | | | | | | | | | | | | | | | | Summary: This reverts commit 56beec1b1cfc6d263e5eddb7efff06117c0724d2. Revert "Quick fix to D32609, it seems .o files are not transferred in all cases." This reverts commit 7652eecd29cfdeeab7f76f687586607a99ff4e36. Revert "Update llvm-readobj -coff-resources to display tree structure." This reverts commit 422b62c4d302cfc92401418c2acd165056081ed7. Reviewers: zturner Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D32958 llvm-svn: 302397
* Hopefully one last commit to fix this patch, addresses string referenceEric Beckmann2017-05-081-2/+6
| | | | | | issues. llvm-svn: 302395
* Update llvm-readobj -coff-resources to display tree structure.Eric Beckmann2017-05-071-8/+93
| | | | | | | | | | | | Summary: Continue making updates to llvm-readobj to display resource sections. This is necessary for testing the up and coming cvtres tool. Reviewers: zturner Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D32609 llvm-svn: 302386
* Make llvm-rtdlyd -check preserve automatic address mappings made by RuntimeDyld.Lang Hames2017-05-071-13/+10
| | | | | | | | | | | | | | | | | Currently llvm-rtdyld in -check mode will map sections to back-to-back 4k aligned slabs starting at 0x1000. Automatically remapping sections by default is helpful because it quickly exposes relocation bugs due to use of local addresses rather than load addresses (these would silently pass if the load address was not remapped). These mappings can be explicitly overridden on a per-section basis using llvm-rtdlyd's -map-section option. This patch extends this scheme to also preserve any mappings made by RuntimeDyld itself. Preserving RuntimeDyld's automatic mappings allows us to write test cases to verify that these automatic mappings have been applied. This will allow the fix in https://reviews.llvm.org/D32899 to be tested with llvm-rtdyld -check. llvm-svn: 302372
* [CodeView] Reserve TypeDatabase records up front.Zachary Turner2017-05-053-7/+7
| | | | | | | | | | | | | Most of the time we know exactly how many type records we have in a list, and we want to use the visitor to deserialize them into actual records in a database. Previously we were just using push_back() every time without reserving the space up front in the vector. This is obviously terrible from a performance standpoint, and it's not uncommon to have PDB files with half a million type records, where the performance degredation was quite noticeable. llvm-svn: 302302
* [WebAssembly] Add ObjectYAML support for wasm name sectionSam Clegg2017-05-052-11/+54
| | | | | | Differential Revision: https://reviews.llvm.org/D32841 llvm-svn: 302266
* [pdb] Don't verify TPI hash values up front.Zachary Turner2017-05-041-6/+16
| | | | | | | | | | | | | | | | | | | | | | | | Verifying the hash values as we are currently doing results in iterating every type record before the user even tries to access the first one, and the API user has no control over, or ability to hook into this process. As a result, when the user wants to iterate over types to print them or index them, this results in a second iteration over the same list of types. When there's upwards of 1,000,000 type records, this is obviously quite undesirable. This patch raises the verification outside of TpiStream , and llvm-pdbdump hooks a hash verification visitor into the normal dumping process. So we still verify the hash records, but we can do it while not requiring a second iteration over the type stream. Differential Revision: https://reviews.llvm.org/D32873 llvm-svn: 302206
* [PDB] Don't build the entire source file list up front.Zachary Turner2017-05-043-36/+45
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | I tried to run llvm-pdbdump on a very large (~1.5GB) PDB to try and identify show-stopping performance problems. This patch addresses the first such problem. When loading the DBI stream, before anyone has even tried to access a single record, we build an in memory map of every source file for every module. In the particular PDB I was using, this was over 85 million files. Specifically, the complexity is O(m*n) where m is the number of modules and n is the average number of source files (including headers) per module. The whole reason for doing this was so that we could have constant time access to any module and any of its source file lists. However, we can still get O(1) access to the source file list for a given module with a simple O(m) precomputation, and access to the list of modules is already O(1) anyway. So this patches reduces the O(m*n) up-front precomputation to an O(m) one, where n is ~6,500 and n*m is about 85 million in my pathological test case. Differential Revision: https://reviews.llvm.org/D32870 llvm-svn: 302205
* [llvm-pdbdump] Only build the TypeDatabase if necessary.Zachary Turner2017-05-042-41/+77
| | | | | | | | | Building the type database is expensive, and can take multiple minutes for large PDBs. But we only need it in certain cases depending on what command line options are specified. So only build it when we know we're about to need it. llvm-svn: 302204
* Re-apply r302108, "IR: Use pointers instead of GUIDs to represent edges in ↵Peter Collingbourne2017-05-042-2/+2
| | | | | | | | the module summary. NFCI." with a fix for the clang backend. llvm-svn: 302176
* Revert "IR: Use pointers instead of GUIDs to represent edges in the module ↵Eric Liu2017-05-042-2/+2
| | | | | | | | | | summary. NFCI." This reverts commit r302108. This causes crash in clang bootstrap with LTO. Contacted the auther in the original commit. llvm-svn: 302140
* IR: Use pointers instead of GUIDs to represent edges in the module summary. ↵Peter Collingbourne2017-05-042-2/+2
| | | | | | | | | | | | | | | | | | | | NFCI. When profiling a no-op incremental link of Chromium I found that the functions computeImportForFunction and computeDeadSymbols were consuming roughly 10% of the profile. The goal of this change is to improve the performance of those functions by changing the map lookups that they were previously doing into pointer dereferences. This is achieved by changing the ValueInfo data structure to be a pointer to an element of the global value map owned by ModuleSummaryIndex, and changing reference lists in the GlobalValueSummary to hold ValueInfos instead of GUIDs. This means that a ValueInfo will take a client directly to the summary list for a given GUID. Differential Revision: https://reviews.llvm.org/D32471 llvm-svn: 302108
* Remove unused private field.Zachary Turner2017-05-031-1/+1
| | | | llvm-svn: 302069
OpenPOWER on IntegriCloud