summaryrefslogtreecommitdiffstats
path: root/llvm/lib/CodeGen/AsmPrinter
Commit message (Collapse)AuthorAgeFilesLines
...
* [CodeGen] Fix some Clang-tidy modernize and Include What You Use warnings; ↵Eugene Zelenko2017-08-1716-220/+360
| | | | | | other minor fixes (NFC). llvm-svn: 311124
* Make .file directive to have basename onlyTaewook Oh2017-08-101-1/+3
| | | | | | | | | | | | | | | Summary: Currently LLVM puts directory along with the filename in .file directive, but this behavior doesn't match gcc. There's a no clear description about which one is right (https://sourceware.org/binutils/docs/as/File.html#File), but one document (https://sourceware.org/gdb/current/onlinedocs/stabs/ELF-Linker-Relocation.html) suggests that STT_FILE symbol in elf file is expected to have basename only, which should have a same sting file .file directive according to (https://docs.oracle.com/cd/E26502_01/html/E28388/eoiyg.html). This also affects badly on the build system that uses hashing, as the directory info could be differnt from developer to developer even when they're working on same file. Reviewers: pcc, mehdi_amini Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D36018 llvm-svn: 310642
* [codeview] Emit nested enums and typedefs from classesReid Kleckner2017-08-081-4/+6
| | | | | | | | | | Previously we limited ourselves to only emitting nested classes, but we need other kinds of types as well. This fixes the Visual Studio STL visualizers, so that users can visualize std::string and other objects. llvm-svn: 310410
* Assert that the offset of a DBG_VALUE is always 0. (NFC)Adrian Prantl2017-08-022-4/+8
| | | | llvm-svn: 309834
* Remove the unused Offset field from MachineLocation (NFC)Adrian Prantl2017-08-022-11/+3
| | | | | | rdar://problem/33580047 llvm-svn: 309831
* Remove unused includes of MachineLocation.h (NFC)Adrian Prantl2017-08-022-1/+1
| | | | llvm-svn: 309824
* Remove unreachable code. (NFC)Adrian Prantl2017-08-024-26/+5
| | | | | | | | MachineLocation::getOffset() always returns 0. rdar://problem/33580047 llvm-svn: 309823
* Remove PrologEpilogInserter's usage of DBG_VALUE's offset fieldAdrian Prantl2017-08-011-5/+16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In the last half-dozen commits to LLVM I removed code that became dead after removing the offset parameter from llvm.dbg.value gradually proceeding from IR towards the backend. Before I can move on to DwarfDebug and friends there is one last side-called offset I need to remove: This patch modifies PrologEpilogInserter's use of the DBG_VALUE's offset argument to use a DIExpression instead. Because the PrologEpilogInserter runs at the Machine level I had to play a little trick with a named llvm.dbg.mir node to get the DIExpressions to print in MIR dumps (which print the llvm::Module followed by the MachineFunction dump). I also had to add rudimentary DwarfExpression support to CodeView and as a side-effect also fixed a bug (CodeViewDebug::collectVariableInfo was supposed to give up on variables with complex DIExpressions, but would fail to do so for fragments, which are also modeled as DIExpressions). With this last holdover removed we will have only one canonical way of representing offsets to debug locations which will simplify the code in DwarfDebug (and future versions of CodeViewDebug once it starts handling more complex expressions) and make it easier to reason about. This patch is NFC-ish: All test case changes are for assembler comments and the binary output does not change. rdar://problem/33580047 Differential Revision: https://reviews.llvm.org/D36125 llvm-svn: 309751
* DebugInfo: Update flag description that'd been copypasted from anotherDavid Blaikie2017-08-011-1/+1
| | | | | | Post-commit review feedback from Paul Robinson on r309630. Thanks Paul! llvm-svn: 309685
* DebugInfo: Put range base specifier entry functionality behind a flagDavid Blaikie2017-07-311-4/+9
| | | | | | | | Chromium's gold build seems to have trouble with this (gold produces errors) - not sure if it's gold that's not coping with the valid representation, or a bug in the implementation in LLVM, etc. llvm-svn: 309630
* [codeview] Ignore DBG_VALUEs when choosing a BB start source locReid Kleckner2017-07-311-0/+2
| | | | | | | | | | When the first instruction of a basic block has no location (consider a LEA materializing the address of an alloca for a call), we want to start the line table for the block with the first valid source location in the block. We need to ignore DBG_VALUE instructions during this scan to get decent line tables. llvm-svn: 309628
* DebugInfo: Fix r309526, ensure resetting base address selection entries are usedDavid Blaikie2017-07-311-0/+6
| | | | | | | Missed the resetting base address selections when going from a base address version to zero base address for non-base-addressed entries. llvm-svn: 309529
* DebugInfo: Use base address selection entries in debug_ranges to reduce ↵David Blaikie2017-07-301-10/+35
| | | | | | | | | | | | | | | | | | | | relocations (from comments in the test) Group ranges in a range list that apply to the same section and use a base address selection entry to reduce the number of relocations to one reloc per section per range list. DWARF5 debug_rnglist will be more efficient than this in terms of relocations, but it's still better than one reloc per entry in a range list. This is an object/executable size tradeoff - shrinking objects, but growing the linked executable. In one large binary tested, total object size (not just debug info) shrank by 16%, entirely relocation entries. Linked executable grew by 4%. This was with compressed debug info in the objects, uncompressed in the linked executable. Without compression in the objects, the win would be smaller (the growth of debug_ranges itself would be more significant). llvm-svn: 309526
* DebugInfo: Consider a CU containing only local imported entities to be 'empty'David Blaikie2017-07-281-11/+14
| | | | | | | | | | | | | | | | | | | | | | | This can come up in ThinLTO & wastes space & makes degenerate IR. As per the added FIXME, ultimately, local imported entities should hang off the function and that way the imported entity list on the CU can be tested for emptiness like all the other CU lists. (function-attached local imported entities are probably also the best path forward for fixing how imported entities are handled both in cross-module use (currently, while ThinLTO preserves the imported entities, they would not get used at the imported inlined location - only in the abstract origin that appears in the partial CU created by the import (which isn't emitted under Fission due to cross-CU limitations there)) and to reduce the number of points where imported entities are emitted (they're currently emitted into every inlined instance, concrete instance, and abstract origin - they should only go in teh abstract origin if there is one, otherwise in the concrete instance - but this requires lots of delayed handling and wiring up, same as abstract variables & subprograms)) llvm-svn: 309354
* remove redundant checkAdrian Prantl2017-07-271-1/+1
| | | | llvm-svn: 309280
* DebugInfo: Ensure imported entities at the top level of an inlined function ↵David Blaikie2017-07-273-17/+18
| | | | | | | | | | | | | | | | | | | | | | don't cause degenerate concrete definitions Local imported entities at the top level of a subprogram were being handled differently from those in nested scopes - that different handling would cause pseudo concrete out-of-line definitions to be created (but without any of their attributes, nor an abstract_origin) in the case where there was no real concrete definition. These local imported entities also only appeared in the concrete definition where those imported entities in nested scopes appear in all cases (abstract, concrete, and inlined). This change at least makes top level case handle the same as the others - though there's a FIXME to improve this to /only/ emit them into the abstract origin (though this requires more plumbing - like the abstract subprogram and variable handling that must defer population until the end of the unit to discover if there is an abstract origin, or only a standalone concrete definition). llvm-svn: 309237
* Do a better job at emitting prefrabricated skeleton CUs.Adrian Prantl2017-07-261-4/+14
| | | | | | | | | | | | | | | | | | | | This is a better fix than r308708 for the problem introduced in r304020. It restores the skeleton CU testcases modified by that commit to their original form and most importantly ensures that frontend-generated skeleton CUs (such as used to point to Clang modules) come after the regular CUs. This broke for DICompileUnit nodes that don't have any immediate children because they are now constructed lazily instead of the order in which they are listed in !llvm.dbg.cu. After this commit we still don't guarantee that order, but we do guarantee that empty skeletons come last. Shipping versions of LLDB are very sensitive to the ordering of CUs. I'll track a fix for LLDB to be more permissive separately. This fixes a test failure in the LLDB testsuite. rdar://problem/33357252 llvm-svn: 309154
* Debug Info: Support fragmented variables in the MMI side tableAdrian Prantl2017-07-251-1/+6
| | | | | | This reapplies commit r309034 with a bugfix+test for inlined variables. llvm-svn: 309057
* Revert "Debug Info: Support fragmented variables in the MMI side table"Adrian Prantl2017-07-251-6/+1
| | | | | | This reverts commit r309034 because of a sanitizer issue. llvm-svn: 309035
* Debug Info: Support fragmented variables in the MMI side tableAdrian Prantl2017-07-251-1/+6
| | | | | | <rdar://problem/17816343> llvm-svn: 309034
* [codeview] Emit 'D' as the cv source language for D codeReid Kleckner2017-07-241-0/+2
| | | | | | | | | This matches DMD: https://github.com/dlang/dmd/blob/522263965cf3a27ed16b31f3c3562db86cdeabec/src/ddmd/backend/cv8.c#L199 Fixes PR33899. llvm-svn: 308890
* Format some case labels and shrink an anonymous namespace NFCReid Kleckner2017-07-241-15/+12
| | | | llvm-svn: 308889
* Debug Info: Don't strip clang module skeleton CUs.Adrian Prantl2017-07-211-1/+2
| | | | | | | | This corrects a (hopefully :-) accidental side-effect of r304020. rdar://problem/33442618 llvm-svn: 308708
* [COFF, ARM64, CodeView] Add support to emit CodeView debug info for ARM64 COFFMandeep Singh Grang2017-07-201-0/+2
| | | | | | | | | | | | Reviewers: compnerd, ruiu, rnk, zturner Reviewed By: rnk Subscribers: majnemer, aemerson, aprantl, javed.absar, kristof.beyls, llvm-commits Differential Revision: https://reviews.llvm.org/D35518 llvm-svn: 308665
* [AsmPrinter] Constify needsCFIMoves. NFCFrancis Visoiu Mistrih2017-07-191-1/+1
| | | | llvm-svn: 308557
* Debug Info: Add a file: field to DIImportedEntity.Adrian Prantl2017-07-191-2/+3
| | | | | | | | | | | | | | | | | | | | | | | DIImportedEntity has a line number, but not a file field. To determine the decl_line/decl_file we combine the line number from the DIImportedEntity with the file from the DIImportedEntity's scope. This does not work correctly when the parent scope is a DINamespace or a DIModule, both of which do not have a source file. This patch adds a file field to DIImportedEntity to unambiguously identify the source location of the using/import declaration. Most testcase updates are mechanical, the interesting one is the removal of the FIXME in test/DebugInfo/Generic/namespace.ll. This fixes PR33822. See https://bugs.llvm.org/show_bug.cgi?id=33822 for more context. <rdar://problem/33357889> https://bugs.llvm.org/show_bug.cgi?id=33822 Differential Revision: https://reviews.llvm.org/D35583 llvm-svn: 308398
* [codeview] Use the first valid source location at the top of every MBBReid Kleckner2017-06-302-5/+18
| | | | | | | | | | | | | | | | If the instructions at the beginning of the block have no location, we're better off using the location of the first instruction in the current basic block. At the very least, that instruction post-dominates this one, whereas if we don't emit a .cv_loc directive, we end up using the potentially invalid location that falls through from the previous block. We could probably do better here by emitting some kind of ".cv_loc end" directive that stops the line table entry of the previous .cv_loc directive from bleeding out of its basic block. This would improve the line table when an entire MBB has no valid location info. llvm-svn: 306889
* Drop the LLVM mangler escape when printing the IR name in assembly commentsReid Kleckner2017-06-301-1/+3
| | | | | | | I'm tired of seeing this: .globl "?Test@@YAXXZ" # -- Begin function ^A?Test@@YAXXZ llvm-svn: 306855
* [DWARF] Move a couple of member functions to the DWARFUnit baseclass. NFC.Wolfgang Pieb2017-06-304-30/+29
| | | | | | | | Reviewer: dblaikie Differential revision: https://reviews.llvm.org/D34765 llvm-svn: 306771
* Mark dump() methods as const. NFCSam Clegg2017-06-211-3/+3
| | | | | | | | | Add const qualifier to any dump() method where adding one was trivial. Differential Revision: https://reviews.llvm.org/D34481 llvm-svn: 305963
* [XRay] Reduce synthetic references emitted by XRayDean Michael Berris2017-06-211-8/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: When we're building with XRay instrumentation, we use a trick that preserves references from the function to a function sled index. This index table lives in a separate section, and without this trick the linker is free to garbage-collect this section and all the segments it refers to. Until we're able to tell the linkers to preserve these sections, we use this reference trick to keep around both the index and the entries in the instrumentation map. Before this change we emitted both a synthetic reference to the label in the instrumentation map, and to the entry in the function map index. This change removes the first synthetic reference and only emits one synthetic reference to the index -- the index entry has the references to the labels in the instrumentation map, so the linker will still preserve those if the function itself is preserved. This reduces the amount of synthetic references we emit from 16 bytes to just 8 bytes in x86_64, and similarly to other platforms. Reviewers: dblaikie Subscribers: javed.absar, kpw, pelikan, llvm-commits Differential Revision: https://reviews.llvm.org/D34340 llvm-svn: 305880
* Fix a crash in DwarfDebug::validThroughout.Adrian Prantl2017-06-201-3/+5
| | | | | | | | | | | The instruction it falls over on is an IMPLICT_DEF that also happens to be the only instruction in its lexical scope. That LexicalScope has never been created because its range is empty. This patch skips over all meta-instructions instead of just DBG_VALUEs. Thanks to David Blaikie for providing a testcase! llvm-svn: 305853
* Improve the accuracy of variable ranges .debug_loc location lists.Adrian Prantl2017-06-161-12/+54
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | For the following motivating example bool c(); void f(); bool start() { bool result = c(); if (!c()) { result = false; goto exit; } f(); result = true; exit: return result; } we would previously generate a single DW_AT_const_value(1) because only the DBG_VALUE in the second-to-last basic block survived codegen. This patch improves the heuristic used to determine when a DBG_VALUE is available at the beginning of its variable's enclosing lexical scope: - Stop giving singular constants blanket permission to take over the entire scope. There is still a special case for constants in the function prologue that we also miight want to retire later. - Use the lexical scope information to determine available-at-entry instead of proximity to the function prologue. After this patch we generate a location list with a more accurate narrower availability for the constant true value. As a pleasant side effect, we also generate inline locations instead of location lists where a loacation covers the entire range of the enclosing lexical scope. Measured on compiling llc with four targets this doesn't have an effect on compile time and reduces the size of the debug info for llc by ~600K. rdar://problem/30286912 llvm-svn: 305599
* Align definition of DW_OP_plus with DWARF spec [3/3]Florian Hahn2017-06-145-20/+23
| | | | | | | | | | | | | | | | | | | | | | | | Summary: This patch is part of 3 patches that together form a single patch, but must be introduced in stages in order not to break things. The way that LLVM interprets DW_OP_plus in DIExpression nodes is basically that of the DW_OP_plus_uconst operator since LLVM expects an unsigned constant operand. This unnecessarily restricts the DW_OP_plus operator, preventing it from being used to describe the evaluation of runtime values on the expression stack. These patches try to align the semantics of DW_OP_plus and DW_OP_minus with that of the DWARF definition, which pops two elements off the expression stack, performs the operation and pushes the result back on the stack. This is done in three stages: • The first patch (LLVM) adds support for DW_OP_plus_uconst. • The second patch (Clang) contains changes all its uses from DW_OP_plus to DW_OP_plus_uconst. • The third patch (LLVM) changes the semantics of DW_OP_plus and DW_OP_minus to be in line with its DWARF meaning. This patch includes the bitcode upgrade from legacy DIExpressions. Patch by Sander de Smalen. Reviewers: echristo, pcc, aprantl Reviewed By: aprantl Subscribers: fhahn, javed.absar, aprantl, llvm-commits Differential Revision: https://reviews.llvm.org/D33894 llvm-svn: 305386
* Align definition of DW_OP_plus with DWARF spec [1/3]Florian Hahn2017-06-131-0/+7
| | | | | | | | | | | | | | | | | | | | | | | | Summary: This patch is part of 3 patches that together form a single patch, but must be introduced in stages in order not to break things. The way that LLVM interprets DW_OP_plus in DIExpression nodes is basically that of the DW_OP_plus_uconst operator since LLVM expects an unsigned constant operand. This unnecessarily restricts the DW_OP_plus operator, preventing it from being used to describe the evaluation of runtime values on the expression stack. These patches try to align the semantics of DW_OP_plus and DW_OP_minus with that of the DWARF definition, which pops two elements off the expression stack, performs the operation and pushes the result back on the stack. This is done in three stages: • The first patch (LLVM) adds support for DW_OP_plus_uconst. • The second patch (Clang) contains changes all its uses from DW_OP_plus to DW_OP_plus_uconst. • The third patch (LLVM) changes the semantics of DW_OP_plus and DW_OP_minus to be in line with its DWARF meaning. This patch includes the bitcode upgrade from legacy DIExpressions. Patch by Sander de Smalen. Reviewers: pcc, echristo, aprantl Reviewed By: aprantl Subscribers: fhahn, aprantl, javed.absar, llvm-commits Differential Revision: https://reviews.llvm.org/D33892 llvm-svn: 305304
* Fix an assertion failure when duplicate dbg.declares are present.Adrian Prantl2017-06-121-0/+7
| | | | | | | | | | This fixes PR33157. https://bugs.llvm.org//show_bug.cgi?id=33157 We might also think about disallowing duplicate dbg.declare intrinsics entirely, but this may complicate some passes needlessly. llvm-svn: 305244
* IR: Replace the "Linker Options" module flag with "llvm.linker.options" ↵Peter Collingbourne2017-06-121-5/+1
| | | | | | | | | | named metadata. The new metadata is easier to manipulate than module flags. Differential Revision: https://reviews.llvm.org/D31349 llvm-svn: 305227
* [CodeGen] Fix some Clang-tidy modernize-use-using and Include What You Use ↵Eugene Zelenko2017-06-071-8/+13
| | | | | | warnings; other minor fixes (NFC). llvm-svn: 304954
* Update libdeps to add BinaryFormat, introduced in r304864.NAKAMURA Takumi2017-06-071-1/+1
| | | | llvm-svn: 304869
* Move Object format code to lib/BinaryFormat.Zachary Turner2017-06-0712-15/+17
| | | | | | | | | | | | This creates a new library called BinaryFormat that has all of the headers from llvm/Support containing structure and layout definitions for various types of binary formats like dwarf, coff, elf, etc as well as the code for identifying a file from its magic. Differential Revision: https://reviews.llvm.org/D33843 llvm-svn: 304864
* [CodeGen] Fix some Clang-tidy modernize-use-using and Include What You Use ↵Eugene Zelenko2017-06-062-31/+92
| | | | | | warnings; other minor fixes (NFC). llvm-svn: 304839
* Sort the remaining #include lines in include/... and lib/....Chandler Carruth2017-06-067-10/+10
| | | | | | | | | | | | | | | | | | | | | | | | | I did this a long time ago with a janky python script, but now clang-format has built-in support for this. I fed clang-format every line with a #include and let it re-sort things according to the precise LLVM rules for include ordering baked into clang-format these days. I've reverted a number of files where the results of sorting includes isn't healthy. Either places where we have legacy code relying on particular include ordering (where possible, I'll fix these separately) or where we have particular formatting around #include lines that I didn't want to disturb in this patch. This patch is *entirely* mechanical. If you get merge conflicts or anything, just ignore the changes in this patch and run clang-format over your #include lines in the files. Sorry for any noise here, but it is important to keep these things stable. I was seeing an increasing number of patches with irrelevant re-ordering of #include lines because clang-format was used. This patch at least isolates that churn, makes it easy to skip when resolving conflicts, and gets us to a clean baseline (again). llvm-svn: 304787
* DbgValueHistoryCalculator: Ignore call instructions that claim to clobber SP.Adrian Prantl2017-06-011-0/+4
| | | | | | | | | | | The AArch64 backend marks calls that involve aggregate function arguments as having an implicit def of SP. We already have the same workaround in LiveDebugValues and in DbgValueHistoryCalculator for SP clobbers in register masks. This adds register defs to the list. Fixes rdar://problem/30361929 and Swift SR-3851. llvm-svn: 304471
* Check hasPersonalityFn before calling getPersonalityFnReid Kleckner2017-05-311-4/+5
| | | | llvm-svn: 304365
* [EH] Fix the LSDA that we emit for unknown EH personalitiesReid Kleckner2017-05-312-5/+16
| | | | | | | | | | | | | | We should have a single call site entry with no landing pad. This indicates that no EH action should be taken and the unwinder should unwind to the next frame. We currently don't recognize __gxx_personality_seh0 as a known personality, so we forcibly emit a table, and that table was wrong. This was filed as PR33220. Now we emit a correct table for that personality. The next step is to recognize that we can completely skip the table for this personality. llvm-svn: 304363
* [CodeView] Rename ModuleDebugFragment -> DebugSubsection.Zachary Turner2017-05-302-10/+9
| | | | | | | This is more concise, and matches the terminology used in other parts of the codebase more closely. llvm-svn: 304218
* DebugInfo: Include .dwo file name when hashing multiple CUs in a single fileMehdi Amini2017-05-293-3/+13
| | | | | | | | | | | | | | | | | | | | | | | This is really a workaround for ThinLTO in particular - since it can import partial CUs that may end up looking very similar/the same as the same partial import in another ThinLTO compile. An alternative fix would be to change the DICompileUnit metadata to include a "primary file" or the like - and when importing for ThinLTO set the primary file to the name of the DICompileUnit that is being imported into. This involves changing the schema and would reduce the excessive uniqueness in the hash that this change creates - allowing diagnosing of more duplicate CUs than will be caught with this change. But duplicate CUs can still be caught in non-ThinLTO builds & are mostly a nuisance rather than a particularly deliberate/effective tool for finding broken code. (arguably the hash could always include the dwo file and nothing in fission would break, I think..) Reapply of r304119 after adding a triple to the test and moving it to the X86 directory. llvm-svn: 304130
* DebugInfo: Omit an empty CU when a subprogram was moved into its useMehdi Amini2017-05-291-8/+12
| | | | | | | | | | | When the only use of a CU is for a subprogram that's only emitted into the using CU (to avoid cross-CU references in DWO files), avoid creating that CU at all. Reapply of r304111 after adding a triple to the test and moving it to the X86 directory. llvm-svn: 304129
* Revert "DebugInfo: Omit an empty CU when a subprogram was moved into its use"Mehdi Amini2017-05-291-12/+8
| | | | | | | This reverts commit r304111. GreenDragon is broken. llvm-svn: 304126
* Revert "DebugInfo: Include .dwo file name when hashing multiple CUs in a ↵Mehdi Amini2017-05-293-13/+3
| | | | | | | | single file" This reverts commit r304119 and r304118. GreenDragon is broken. llvm-svn: 304125
OpenPOWER on IntegriCloud