summaryrefslogtreecommitdiffstats
path: root/llvm/tools
Commit message (Collapse)AuthorAgeFilesLines
* [DWARF] Adding support for the DWARF v5 string offsets table ↵Wolfgang Pieb2017-06-062-0/+2
| | | | | | | | | | (consumer/reader part only). Reviewers: dblaikie, aprantl Differential Revision: https://reviews.llvm.org/D32779 llvm-svn: 304759
* CodeGen: Refactor MIR parsingMatthias Braun2017-06-061-2/+3
| | | | | | | | | | | | When parsing .mir files immediately construct the MachineFunctions and put them into MachineModuleInfo. This allows us to get rid of the delayed construction (and delayed error reporting) through the MachineFunctionInitialzier interface. Differential Revision: https://reviews.llvm.org/D33809 llvm-svn: 304758
* llc: Create custom pass pipeline for .mir files; NFCIMatthias Braun2017-06-061-34/+46
| | | | | | | | | | Create a custom pass pipeline when loading .mir files even in --start-after/--start-before cases. This streamlines the mir handling code and prepares for an upcoming commit. llvm-svn: 304755
* [CodeView] Handle Cross Module Imports and Exports.Zachary Turner2017-06-054-8/+63
| | | | | | | | | | | | | | | While it's not entirely clear why a compiler or linker might put this information into an object or PDB file, one has been spotted in the wild which was causing llvm-pdbdump to crash. This patch adds support for reading-writing these sections. Since I don't know how to get one of the native tools to generate this kind of debug info, the only test here is one in which we feed YAML into the tool to produce a PDB and then spit out YAML from the resulting PDB and make sure that it matches. llvm-svn: 304738
* AMDGPU: Remove deprecated and unused elf definitionsKonstantin Zhuravlyov2017-06-051-29/+1
| | | | | | Differential Revision: https://reviews.llvm.org/D33689 llvm-svn: 304737
* Symbols re-defined with -wrap and -defsym need to be excluded from inter-Dmitry Mikulin2017-06-051-0/+2
| | | | | | | | | | procedural optimizations to prevent dropping symbols and allow the linker to process re-directs. PR33145: --wrap doesn't work with lto. Differential Revision: https://reviews.llvm.org/D33621 llvm-svn: 304719
* [PDB] Fix use after free.Zachary Turner2017-06-033-5/+6
| | | | | | | | | | | | | | | | | | | | | | | Previously MappedBlockStream owned its own BumpPtrAllocator that it would allocate from when a read crossed a block boundary. This way it could still return the user a contiguous buffer of the requested size. However, It's not uncommon to open a stream, read some stuff, close it, and then save the information for later. After all, since the entire file is mapped into memory, the data should always be available as long as the file is open. Of course, the exception to this is when the data isn't *in* the file, but rather in some buffer that we temporarily allocated to present this contiguous view. And this buffer would get destroyed as soon as the strema was closed. The fix here is to force the user to specify the allocator, this way it can provide an allocator that has whatever lifetime it chooses. Differential Revision: https://reviews.llvm.org/D33858 llvm-svn: 304623
* RegisterScavenging: Add ScavengerTest passMatthias Braun2017-06-021-0/+3
| | | | | | | | | This pass allows to run the register scavenging independently of PrologEpilogInserter to allow targeted testing. Also adds some basic register scavenging tests. llvm-svn: 304606
* [CodeView] Support CodeView subsections in any order.Zachary Turner2017-06-026-183/+34
| | | | | | | | | | | | | | | Previously we would expect certain subsections to appear in a certain order because some subsections would reference other subsections, but in practice we need to support arbitrary orderings since some object file and PDB file producers generate them this way. This also paves the way for supporting Yaml <-> Object File conversion of CodeView, since Object Files typically have quite a large number of subsections in their debug info. Differential Revision: https://reviews.llvm.org/D33807 llvm-svn: 304588
* [ThinLTO] Move -lto-use-new-pm to llvm-lto2, and change it to -use-new-pm.Tim Shen2017-06-011-1/+7
| | | | | | | | | | | | | | | | | | Summary: As we teach Clang to use ThinkLTO + new PM, it's good for the users to inject through Config, instead of setting a flag in the LTOBackend library. Move the flag to llvm-lto2. As it moves to llvm-lto2, a new name -use-new-pm seems simpler and as clear. Reviewers: davide, tejohnson Subscribers: mehdi_amini, Prazek, inglorion, eraman, chandlerc, llvm-commits Differential Revision: https://reviews.llvm.org/D33799 llvm-svn: 304492
* [CodeView] Properly align symbol records on read/write.Zachary Turner2017-06-013-5/+9
| | | | | | | | | | | | | | | | | Object files have symbol records not aligned to any particular boundary (e.g. 1-byte aligned), while PDB files have symbol records padded to 4-byte aligned boundaries. Since they share the same reading / writing code, we have to provide an option to specify the alignment and propagate it up to the producer or consumer who knows what the alignment is supposed to be for the given container type. Added a test for this by modifying the existing PDB -> YAML -> PDB round-tripping code to round trip symbol records as well as types. Differential Revision: https://reviews.llvm.org/D33785 llvm-svn: 304484
* [llvm-config] Don't use PATH_MAXKeno Fischer2017-06-011-1/+1
| | | | | | | | It doesn't exist on Windows. The number we use here doesn't really matter, the storage will expand automatically but 256 seems like a reasonable default. Should fix windows buildbots that complained about rL304458. llvm-svn: 304468
* [llvm-config] Report --bindir based on LLVM_TOOLS_INSTALL_DIRKeno Fischer2017-06-012-1/+4
| | | | | | | | | | | | | | | | | | | Summary: `LLVM_TOOLS_INSTALL_DIR` was introduced in r272200 in order to override the directory name into which to install LLVM's executable. However, `llvm-config --bindir` still reported `$PREFIX/bin` independent of what LLVM_TOOLS_INSTALL_DIR was set to. This fixes the out-of-tree clang standalone build for me. Reviewers: beanz, tstellar Reviewed By: tstellar Subscribers: chapuni, tstellar, llvm-commits Differential Revision: https://reviews.llvm.org/D22499 llvm-svn: 304458
* Prefer static namespace-scoped variables over anon namespacing per style guideDavid Blaikie2017-06-011-6/+5
| | | | | | | Also for consistency with the immediately preceeding variable definition. llvm-svn: 304457
* [DWARF] Introduce Dump OptionsAdrian Prantl2017-06-013-3/+13
| | | | | | | | | | | This commit introduces a structure that holds all the flags that control the pretty printing of dwarf output. Patch by Spyridoula Gravani! Differential Revision: https://reviews.llvm.org/D33749 llvm-svn: 304446
* [ThinLTO] Migrate ThinLTOBitcodeWriter to the new PM.Tim Shen2017-06-013-8/+23
| | | | | | | | | | | | Summary: Also see D33429 for other ThinLTO + New PM related changes. Reviewers: davide, chandlerc, tejohnson Subscribers: mehdi_amini, Prazek, cfe-commits, inglorion, llvm-commits, eraman Differential Revision: https://reviews.llvm.org/D33525 llvm-svn: 304378
* [ObjectYAML] Split CodeViewYAML into 3 pieces.Zachary Turner2017-05-314-3/+4
| | | | | | | | | The code was a mess and disorganized due to the sheer amount of it being in one file. So I'm splitting this into three files. One for CodeView types, one for CodeView symbols, and one for CodeView debug subsections. NFC. llvm-svn: 304278
* Added LLVM_FALLTHROUGH to address warning: this statement may fall through. NFC.Galina Kistanova2017-05-311-0/+2
| | | | llvm-svn: 304273
* Added LLVM_FALLTHROUGH to address warning: this statement may fall through. NFC.Galina Kistanova2017-05-311-0/+1
| | | | llvm-svn: 304268
* [ObjectYAML] Clean up the CodeView headers a bit.Zachary Turner2017-05-311-1/+0
| | | | | | | | | | | | CodeViewYAML.h attempts to hide the details of many of the CodeView yaml structures and types, but at the same time it exposes the mapping traits for them to external users of the header. This patch just hides these in the implementation files so that the interface is kept as simple as possible. llvm-svn: 304263
* [CodeView] Move CodeView symbol yaml logic to ObjectYAML.Zachary Turner2017-05-307-514/+7
| | | | | | | | This continues the effort to get the CodeView YAML parsing logic into ObjectYAML. After this patch, the only missing piece will be the CodeView debug symbol subsections. llvm-svn: 304256
* [CodeView] Move CodeView YAML code to ObjectYAML.Zachary Turner2017-05-3013-1125/+69
| | | | | | | | | | | | | | | | | | | | | | This is the beginning of an effort to move the codeview yaml reader / writer into ObjectYAML so that it can be shared. Currently the only consumer / producer of CodeView YAML is llvm-pdbdump, but CodeView can exist outside of PDB files, and indeed is put into object files and passed to the linker to produce PDB files. Furthermore, there are subtle differences in the types of records that show up in object file CodeView vs PDB file CodeView, but they are otherwise 99% the same. By having this code in ObjectYAML, we can have llvm-pdbdump reuse this code, while teaching obj2yaml and yaml2obj to use this syntax for dealing with object files that can contain CodeView. This patch only adds support for CodeView type information to ObjectYAML. Subsequent patches will add support for CodeView symbol information. llvm-svn: 304248
* Adding parsing ability for .res file.Eric Beckmann2017-05-301-12/+20
| | | | | | | | Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D33566 llvm-svn: 304225
* [CodeView] Add more DebugSubsection implementations.Zachary Turner2017-05-302-85/+30
| | | | | | | | This adds implementations for Symbols and FrameData, and renames the existing codeview::StringTable class to conform to the DebugSectionStringTable convention. llvm-svn: 304222
* [CodeView] Rename ModuleDebugFragment -> DebugSubsection.Zachary Turner2017-05-306-68/+67
| | | | | | | This is more concise, and matches the terminology used in other parts of the codebase more closely. llvm-svn: 304218
* [llvm-pdbdump] pdb2yaml: add an -all option to dump everything we canBob Haarman2017-05-263-0/+18
| | | | | | | | | | | | Reviewers: amccarth, rnk, zturner Reviewed By: zturner Subscribers: fhahn, llvm-commits Differential Revision: https://reviews.llvm.org/D33613 llvm-svn: 304047
* [llvm-pdbdump] Don't crash when displaying padding.Zachary Turner2017-05-261-1/+2
| | | | | | | | | | | | | | | | | | We have a lot of complicated logic to determine where padding is in a record, and the debug info doesn't always provide enough information to figure it out with laser precision. In this case we were putting the padding in the wrong place causing an out of bounds access on a BitVector. Right now we decide that any trailing padding of a child type will be truncated during record layout, but this is only true insofar as the class still is sized properly to end on an alignment boundary, which the algorithm doesn't yet know about. For now, just don't crash, even though we display padding twice in this case. llvm-svn: 303946
* [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
OpenPOWER on IntegriCloud