summaryrefslogtreecommitdiffstats
path: root/llvm/lib/CodeGen/AsmPrinter
Commit message (Collapse)AuthorAgeFilesLines
...
* Don't generate line&scope debug info for meta-instructions.Adrian Prantl2017-05-223-7/+7
| | | | | | | | | | | MachineInstructions that don't generate any code (such as IMPLICIT_DEFs) should not generate any debug info either. Fixes PR33107. https://bugs.llvm.org/show_bug.cgi?id=33107 llvm-svn: 303566
* Resubmit "[CodeView] Provide a common interface for type collections."Zachary Turner2017-05-191-28/+13
| | | | | | | | | | | | 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
* Revert "[CodeView] Provide a common interface for type collections."Zachary Turner2017-05-191-12/+28
| | | | | | | | | | | | | | | | | | 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 another warning.Zachary Turner2017-05-181-1/+1
| | | | llvm-svn: 303394
* [CodeView] Provide a common interface for type collections.Zachary Turner2017-05-181-28/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* [CodeView] Simplify the use of visiting type records & streams.Zachary Turner2017-05-171-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* BitVector: add iterators for set bitsFrancis Visoiu Mistrih2017-05-171-2/+1
| | | | | | Differential revision: https://reviews.llvm.org/D32060 llvm-svn: 303227
* IR: Give function GlobalValue::getRealLinkageName() a less misleading name: ↵Peter Collingbourne2017-05-163-9/+9
| | | | | | | | | | | | dropLLVMManglingEscape(). This function gives the wrong answer on some non-ELF platforms in some cases. The function that does the right thing lives in Mangler.h. To try to discourage people from using this function, give it a different name. Differential Revision: https://reviews.llvm.org/D33162 llvm-svn: 303134
* [codeview] Fix assertion failure introduced in r295354 refactoringReid Kleckner2017-05-121-2/+1
| | | | | | | | CodeViewDebug sets Asm to nullptr to disable debug info generation. You can get a .ll file like no-cus.ll from 'clang -gcodeview -g0', which happens in the ubsan test suite. llvm-svn: 302923
* DWARF: Avoid cross-CU references under FissionDavid Blaikie2017-05-127-70/+116
| | | | | | | | | | | | | | | | | | Turns out that the Fission/Split DWARF package format (DWP) is currently insufficient to handle cross-CU (ref_addr) references. So for now, duplicate any debug info needed in these situations: * inlined_subroutine's abstract_origin * inlined variable's abstract_origin * types Keep the ref_addr behavior in general, including in the split DWARF inline debug info that can be emitted into the object files for online symbolication. Keep a flag to use the old (ref_addr) behavior for testing ways of addressing this limitation in the DWP tool (& for those not using DWP packaging). llvm-svn: 302858
* [codeview] Check for a DIExpression offset for local variablesReid Kleckner2017-05-091-1/+9
| | | | | | | | Fixes inalloca parameters, which previously all pointed to the same offset. Extend the test to use llvm-readobj so that we can test the offset in a readable way. llvm-svn: 302578
* [CodeView] Reserve TypeDatabase records up front.Zachary Turner2017-05-051-1/+1
| | | | | | | | | | | | | 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
* [XRay] Use wordsize-dependent alignment for indexDean Michael Berris2017-05-041-3/+3
| | | | | | | | | | This makes it simpler for the runtime to consistently handle the entries in the function sled index in both 32 and 64 bit platforms where the XRay runtime works. Follow-up on D32693. llvm-svn: 302111
* [XRay] Create an Index of sleds per functionDean Michael Berris2017-05-041-13/+39
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This change adds a new section to the xray-instrumented binary that stores an index into ranges of the instrumentation map, where sleds associated with the same function can be accessed as an array. At runtime, we can get access to this index by function ID offset allowing for selective patching and unpatching by function ID. Each entry in this new section (xray_fn_idx) will include two pointers indicating the start and one past the end of the sleds associated with the same function. These entries will be 16 bytes long on x86 and aarch64. On arm, we align to 16 bytes anyway so the runtime has to take that into consideration. __{start,stop}_xray_fn_idx will be the symbols that the runtime will look for when we implement the selective patching/unpatching by function id APIs. Because XRay synthesizes the function id's in a monotonically increasing manner at runtime now, implementations (and users) can use this table to look up the sleds associated with a specific function. This is useful in implementations that want to do things like: - Implement coverage mode for functions by patching everything pre-main, then as functions are encountered, the installed handler can unpatch the function that's been encountered after recording that it's been called. - Do "learning mode", so that the implementation can figure out some statistical information about function calls by function id for a time being, and then determine which functions are worth uninstrumenting at runtime. - Do "selective instrumentation" where an implementation can specifically instrument only certain function id's at runtime (either based on some external data, or through some other heuristics) instead of patching all the instrumented functions at runtime. Reviewers: dblaikie, echristo, chandlerc, javed.absar Subscribers: pelikan, aemerson, kpw, llvm-commits, rengolin Differential Revision: https://reviews.llvm.org/D32693 llvm-svn: 302109
* DebugInfo: elide type index entries for synthetic typesSaleem Abdulrasool2017-05-031-4/+6
| | | | | | | | | | | | | | Compiler emitted synthetic types may not have an associated DIFile (translation unit). In such a case, when generating CodeView debug type information, we would attempt to compute an absolute filepath which would result in a segfault due to a NULL DIFile*. If there is no source file associated with the type, elide the type index entry for the type and record the type information. This actually results in higher fidelity debug information than clang/C2 as of this writing. Resolves PR32668! llvm-svn: 302085
* [PDB/CodeView] Read/write codeview inlinee line information.Zachary Turner2017-05-021-0/+1
| | | | | | | | Previously we wrote line information and file checksum information, but we did not write information about inlinee lines and functions. This patch adds support for that. llvm-svn: 301936
* Remove line and file from DINamespace.Adrian Prantl2017-04-282-6/+0
| | | | | | | | | | | | | | Fixes the issue highlighted in http://lists.llvm.org/pipermail/cfe-dev/2014-June/037500.html. The DW_AT_decl_file and DW_AT_decl_line attributes on namespaces can prevent LLVM from uniquing types that are in the same namespace. They also don't carry any meaningful information. rdar://problem/17484998 Differential Revision: https://reviews.llvm.org/D32648 llvm-svn: 301706
* Rename some PDB classes.Zachary Turner2017-04-272-8/+9
| | | | | | | | | | | | | | | | | | | We have a lot of very similarly named classes related to dealing with module debug info. This patch has NFC, it just renames some classes to be more descriptive (albeit slightly more to type). The mapping from old to new class names is as follows: Old | New ModInfo | DbiModuleDescriptor ModuleSubstream | ModuleDebugFragment ModStream | ModuleDebugStream With the corresponding Builder classes renamed accordingly. Differential Revision: https://reviews.llvm.org/D32506 llvm-svn: 301555
* Turn DISubprogram into a variable-length node.Adrian Prantl2017-04-262-5/+5
| | | | | | | | | | | | | | | | | | | | DISubprogram currently has 10 pointer operands, several of which are often nullptr. This patch reduces the amount of memory allocated by DISubprogram by rearranging the operands such that containing type, template params, and thrown types come last, and are only allocated when they are non-null (or followed by non-null operands). This patch also eliminates the entirely unused DisplayName operand. This saves up to 4 pointer operands per DISubprogram. (I tried measuring the effect on peak memory usage on an LTO link of an X86 llc, but the results were very noisy). This reapplies r301498 with an attempted workaround for g++. Differential Revision: https://reviews.llvm.org/D32560 llvm-svn: 301501
* Revert "Turn DISubprogram into a variable-length node."Adrian Prantl2017-04-262-5/+5
| | | | | | This reverts commit r301498 while investigating bot breakage. llvm-svn: 301499
* Turn DISubprogram into a variable-length node.Adrian Prantl2017-04-262-5/+5
| | | | | | | | | | | | | | | | DISubprogram currently has 10 pointer operands, several of which are often nullptr. This patch reduces the amount of memory allocated by DISubprogram by rearranging the operands such that containing type, template params, and thrown types come last, and are only allocated when they are non-null (or followed by non-null operands). This patch also eliminates the entirely unused DisplayName operand. This saves up to 4 pointer operands per DISubprogram. (I tried measuring the effect on peak memory usage on an LTO link of an X86 llc, but the results were very noisy). llvm-svn: 301498
* Add support for DW_TAG_thrown_type.Adrian Prantl2017-04-262-0/+13
| | | | | | | | | | | | | | | | | | | | For Swift we would like to be able to encode the error types that a function may throw, so the debugger can display them alongside the function's return value when finish-ing a function. DWARF defines DW_TAG_thrown_type (intended to be used for C++ throw() declarations) that is a perfect fit for this purpose. This patch wires up support for DW_TAG_thrown_type in LLVM by adding a list of thrown types to DISubprogram. To offset the cost of the extra pointer, there is a follow-up patch that turns DISubprogram into a variable-length node. rdar://problem/29481673 Differential Revision: https://reviews.llvm.org/D32559 llvm-svn: 301489
* PR31007 and PR27884 will be closed: a possibility to compile constants like ↵Andrew V. Tischenko2017-04-261-0/+3
| | | | | | 0bH is now supported in MS asm. llvm-svn: 301390
* Fix an assertion when skipping stack values in DWARF2 mode.Adrian Prantl2017-04-251-1/+5
| | | | | | | | The fix consists of resetting LocationKind when addMachineRegExpression fails. rdar://problem/31803010 llvm-svn: 301351
* Print complete DIExpressions in the assembler output DEBUG_VALUE comments.Adrian Prantl2017-04-251-34/+16
| | | | | | The previous code was complex, incorrect, and couldn't print everything. llvm-svn: 301333
* Bring back the ability opt out of padding zero-byte functions by not ↵Daniel Sanders2017-04-251-2/+7
| | | | | | | | | | | | | | providing a nop instruction. Summary: No test case since I'm not aware of an in-tree target that needs this. Reviewers: hans Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D32398 llvm-svn: 301311
* Move size and alignment information of regclass to TargetRegisterInfoKrzysztof Parzyszek2017-04-241-2/+3
| | | | | | | | | | | | | | | 1. RegisterClass::getSize() is split into two functions: - TargetRegisterInfo::getRegSizeInBits(const TargetRegisterClass &RC) const; - TargetRegisterInfo::getSpillSize(const TargetRegisterClass &RC) const; 2. RegisterClass::getAlignment() is replaced by: - TargetRegisterInfo::getSpillAlignment(const TargetRegisterClass &RC) const; This will allow making those values depend on subtarget features in the future. Differential Revision: https://reviews.llvm.org/D31783 llvm-svn: 301221
* Don't emit CFI instructions at the end of a functionAdrian Prantl2017-04-241-0/+10
| | | | | | | | | | | | | | | | | | | | | | | | | When functions are terminated by unreachable instructions, the last instruction might trigger a CFI instruction to be generated. However, emitting it would be be illegal since the function (and thus the FDE the CFI is in) has already ended with the previous instruction. Darwin's dwarfdump --verify --eh-frame complains about this and the specification supports this. Relevant bits from the DWARF 5 standard (6.4 Call Frame Information): "[The] address_range [field in an FDE]: The number of bytes of program instructions described by this entry." "Row creation instructions: [...] The new location value is always greater than the current one." The first quotation implies that a CFI cannot describe a target address outside of the enclosing FDE's range. rdar://problem/26244988 Differential Revision: https://reviews.llvm.org/D32246 llvm-svn: 301219
* Add a testcase for DIExpression(DW_OP_stack_value)Adrian Prantl2017-04-242-1/+2
| | | | | | | | and relax the assertion that prohibited its emission. This fixes the assertion failure uncovered by r301093. llvm-svn: 301209
* Avoid using relocations for ref_addr in .dwo filesDavid Blaikie2017-04-223-13/+14
| | | | | | | | | | In dwo files the fixed offset can be used - if the dwos are linked into a dwp, the dwo consumer must use the dwp tables to find out where the original range of the debug_info was and resolve the "section relative" value relative to that original range - effectively avoiding/reimplementing the relocation handling. llvm-svn: 301072
* Remove the unnecessary virtual dtor from the DIEUnit hierarchy (in favor of ↵David Blaikie2017-04-222-4/+4
| | | | | | | | | protected dtor in the base, final derived classes with public non-virtual dtors) These objects are never polymorphically owned/destroyed, so the virtual dtor was unnecessary. llvm-svn: 301068
* Move Split DWARF handling to an MC option/command line argument rather than ↵David Blaikie2017-04-211-15/+4
| | | | | | | | | | | | | | | | | | | using metadata Since Split DWARF needs to name the actual .dwo file that is generated, it can't be known at the time the llvm::Module is produced as it may be merged with other Modules before the object is generated and that object may be generated with any name. By passing the Split DWARF file name when LLVM is producing object code the .dwo file name in the object file can match correctly. The support for Split DWARF for implicit modules remains the same - using metadata to store the dwo name and dwo id so that potentially multiple skeleton CUs referring to different dwo files can be generated from one llvm::Module. llvm-svn: 301062
* Re-commit r301040 "X86: Don't emit zero-byte functions on Windows"Hans Wennborg2017-04-211-7/+10
| | | | | | | | | In addition to the original commit, tighten the condition for when to pad empty functions to COFF Windows. This avoids running into problems when targeting e.g. Win32 AMDGPU, which caused test failures when this was committed initially. llvm-svn: 301047
* Revert r301040 "X86: Don't emit zero-byte functions on Windows"Hans Wennborg2017-04-211-9/+7
| | | | | | This broke almost all bots. Reverting while fixing. llvm-svn: 301041
* X86: Don't emit zero-byte functions on WindowsHans Wennborg2017-04-211-7/+9
| | | | | | | | | | | | | | | | | | Empty functions can lead to duplicate entries in the Guard CF Function Table of a binary due to multiple functions sharing the same RVA, causing the kernel to refuse to load that binary. We had a terrific bug due to this in Chromium. It turns out we were already doing this for Mach-O in certain situations. This patch expands the code for that in AsmPrinter::EmitFunctionBody() and renames TargetInstrInfo::getNoopForMachoTarget() to simply getNoop() since it seems it was used for not just Mach-O anyway. Differential Revision: https://reviews.llvm.org/D32330 llvm-svn: 301040
* Don't emit locations that need a DW_OP_stack_value in DWARF 2 & 3.Adrian Prantl2017-04-202-1/+10
| | | | | | https://bugs.llvm.org/show_bug.cgi?id=32382 llvm-svn: 300883
* [DWARF] Versioning for DWARF constants; verify FORMsPaul Robinson2017-04-201-4/+13
| | | | | | | | | | | | | Associate the version-when-defined with definitions of standard DWARF constants. Identify the "vendor" for DWARF extensions. Use this information to verify FORMs in .debug_abbrev are defined as of the DWARF version specified in the associated unit. Removed two tests that had specified DWARF v1 (which essentially does not exist). Differential Revision: http://reviews.llvm.org/D30785 llvm-svn: 300875
* Fix bug that caused DwarfExpression to drop DW_OP_deref from FI locationsAdrian Prantl2017-04-195-19/+27
| | | | | | | | | | | - introduced in r300522 and found via the Swift LLDB testsuite. The fix is to set the location kind to memory whenever an FrameIndex location is emitted. rdar://problem/31707602 llvm-svn: 300793
* Revert "Fix bug that caused DwarfExpression to drop DW_OP_deref from FI ↵Adrian Prantl2017-04-195-27/+19
| | | | | | | | locations" This reverts commit r300790. llvm-svn: 300792
* Fix bug that caused DwarfExpression to drop DW_OP_deref from FI locationsAdrian Prantl2017-04-195-19/+27
| | | | | | | | | | | - introduced in r300522 and found via the Swift LLDB testsuite. The fix is to set the location kind to memory whenever an FrameIndex location is emitted. rdar://problem/31707602 llvm-svn: 300790
* [APInt] Use lshrInPlace to replace lshr where possibleCraig Topper2017-04-181-1/+1
| | | | | | | | | | This patch uses lshrInPlace to replace code where the object that lshr is called on is being overwritten with the result. This adds an lshrInPlace(const APInt &) version as well. Differential Revision: https://reviews.llvm.org/D32155 llvm-svn: 300566
* PR32382: Fix emitting complex DWARF expressions.Adrian Prantl2017-04-186-86/+122
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The DWARF specification knows 3 kinds of non-empty simple location descriptions: 1. Register location descriptions - describe a variable in a register - consist of only a DW_OP_reg 2. Memory location descriptions - describe the address of a variable 3. Implicit location descriptions - describe the value of a variable - end with DW_OP_stack_value & friends The existing DwarfExpression code is pretty much ignorant of these restrictions. This used to not matter because we only emitted very short expressions that we happened to get right by accident. This patch makes DwarfExpression aware of the rules defined by the DWARF standard and now chooses the right kind of location description for each expression being emitted. This would have been an NFC commit (for the existing testsuite) if not for the way that clang describes captured block variables. Based on how the previous code in LLVM emitted locations, DW_OP_deref operations that should have come at the end of the expression are put at its beginning. Fixing this means changing the semantics of DIExpression, so this patch bumps the version number of DIExpression and implements a bitcode upgrade. There are two major changes in this patch: I had to fix the semantics of dbg.declare for describing function arguments. After this patch a dbg.declare always takes the *address* of a variable as the first argument, even if the argument is not an alloca. When lowering a DBG_VALUE, the decision of whether to emit a register location description or a memory location description depends on the MachineLocation — register machine locations may get promoted to memory locations based on their DIExpression. (Future) optimization passes that want to salvage implicit debug location for variables may do so by appending a DW_OP_stack_value. For example: DBG_VALUE, [RBP-8] --> DW_OP_fbreg -8 DBG_VALUE, RAX --> DW_OP_reg0 +0 DBG_VALUE, RAX, DIExpression(DW_OP_deref) --> DW_OP_reg0 +0 All testcases that were modified were regenerated from clang. I also added source-based testcases for each of these to the debuginfo-tests repository over the last week to make sure that no synchronized bugs slip in. The debuginfo-tests compile from source and run the debugger. https://bugs.llvm.org/show_bug.cgi?id=32382 <rdar://problem/31205000> Differential Revision: https://reviews.llvm.org/D31439 llvm-svn: 300522
* Distinguish between code pointer size and DataLayout::getPointerSize() in ↵Konstantin Zhuravlyov2017-04-175-17/+19
| | | | | | DWARF info generation llvm-svn: 300463
* This patch closes PR#32216: Better testing of schedule model instruction ↵Andrew V. Tischenko2017-04-141-10/+36
| | | | | | | | latencies/throughputs. The details are here: https://reviews.llvm.org/D30941 llvm-svn: 300311
* Move llvm::canBeOmittedFromSymbolTable() to Analysis.Peter Collingbourne2017-03-311-0/+1
| | | | llvm-svn: 299182
* If the DIUnit has flags passed on it then have DW_AT_producer be a ↵Eric Christopher2017-03-291-1/+8
| | | | | | | | | | combination of DICompileUnit::Producer and Flags. The darwin behavior is unchanged and will continue to use DW_AT_APPLE_flags. Patch by Zhizhou Yang llvm-svn: 299038
* Remove redundant check for nullptr.Adrian Prantl2017-03-271-2/+2
| | | | llvm-svn: 298866
* Remove unneccessary virtual destructor from DwarfExpression.Adrian Prantl2017-03-271-3/+3
| | | | llvm-svn: 298865
* [codeview] Don't assert when the user violates the ODRReid Kleckner2017-03-241-28/+2
| | | | | | | | | | If we have an array of a user-defined aggregates for which there was an ODR violation, then the array size will not necessarily match the number of elements times the size of the element. Fixes PR32383 llvm-svn: 298750
* Refactor code to reduce indentation and improve readability. (NFC)Adrian Prantl2017-03-231-43/+53
| | | | llvm-svn: 298665
OpenPOWER on IntegriCloud