summaryrefslogtreecommitdiffstats
path: root/llvm/lib/CodeGen/AsmPrinter
Commit message (Collapse)AuthorAgeFilesLines
...
* Use llvm::stable_sortFangrui Song2019-04-233-24/+22
| | | | | | While touching the code, simplify if feasible. llvm-svn: 358996
* DebugInfo: Emit only one kind of accelerated access/name tableDavid Blaikie2019-04-223-3/+8
| | | | | | | | | | | | | | | Currently to opt in to debug_names in DWARFv5, the IR must contain 'nameTableKind: Default' which also enables debug_pubnames. Instead, only allow one of {debug_names, apple_names, debug_pubnames, debug_gnu_pubnames}. nameTableKind: Default gives debug_names in DWARFv5 and greater, debug_pubnames in v4 and earlier - and apple_names when tuning for lldb on MachO. nameTableKind: GNU always gives gnu_pubnames llvm-svn: 358931
* [MS] Emit S_HEAPALLOCSITE debug infoAmy Huang2019-04-192-0/+19
| | | | | | | | | | | | | | | | | Summary: This emits labels around heapallocsite calls and S_HEAPALLOCSITE debug info in codeview. Currently only changes FastISel, so emitting labels still needs to be implemented in SelectionDAG. Reviewers: hans, rnk Subscribers: aprantl, hiraditya, cfe-commits, llvm-commits Tags: #clang, #llvm Differential Revision: https://reviews.llvm.org/D60800 llvm-svn: 358783
* [llvm] Prevent duplicate files in debug line header in dwarf 5: another attemptAli Tamur2019-04-191-2/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Another attempt to land the changes in debug line header to prevent duplicate files in Dwarf 5. I rolled back my previous commit because of a mistake in generating the object file in a test. Meanwhile, I addressed some offline comments and changed the implementation; the largest difference is that MCDwarfLineTableHeader does not keep DwarfVersion but gets it as a parameter. I also merged the patch to fix two lld tests that will strt to fail into this patch. Original Commit: https://reviews.llvm.org/D59515 Original Message: Motivation: In previous dwarf versions, file name indexes started from 1, and the primary source file was not explicit. Dwarf 5 standard (6.2.4) prescribes the primary source file to be explicitly given an entry with an index number 0. The current implementation honors the specification by just duplicating the main source file, once with index number 0, and later maybe with another index number. While this is compliant with the letter of the standard, the duplication causes problems for consumers of this information such as lldb. (Some files are duplicated, where only some of them have a line table although all refer to the same file) With this change, dwarf 5 debug line section files always start from 0, and the zeroth entry is not duplicated whenever possible. This requires different handling of dwarf 4 and dwarf 5 during generation (e.g. when a function returns an index zero for a file name, it signals an error in dwarf 4, but not in dwarf 5) However, I think the minor complication is worth it, because it enables all consumers (lldb, gdb, dwarfdump, objdump, and so on) to treat all files in the file name list homogenously. llvm-svn: 358732
* Fix a typo in comments. [NFC]Ali Tamur2019-04-181-1/+1
| | | | llvm-svn: 358639
* [AsmPrinter] hoist %a output template to base class for ARM+Aarch64Nick Desaulniers2019-04-171-4/+11
| | | | | | | | | | | | | | | | | | | | | Summary: X86 is quite complicated; so I intend to leave it as is. ARM+Aarch64 do basically the same thing (Aarch64 did not correctly handle immediates, ARM has a test llvm/test/CodeGen/ARM/2009-04-06-AsmModifier.ll that uses %a with an immediate) for a flag that should be target independent anyways. Reviewers: echristo, peter.smith Reviewed By: echristo Subscribers: javed.absar, eraman, kristof.beyls, hiraditya, llvm-commits, srhines Tags: #llvm Differential Revision: https://reviews.llvm.org/D60841 llvm-svn: 358618
* [AsmPrinter] defer %c to base class for ARM, PPC, and Hexagon. NFCNick Desaulniers2019-04-171-0/+3
| | | | | | | | | | | | | | | | | | | Summary: None of these derived classes do anything that the base class cannot. If we remove these case statements, then the base class can handle them just fine. Reviewers: peter.smith, echristo Reviewed By: echristo Subscribers: nemanjai, javed.absar, eraman, kristof.beyls, hiraditya, kbarton, jsji, llvm-commits, srhines Tags: #llvm Differential Revision: https://reviews.llvm.org/D60803 llvm-svn: 358603
* Revert r358268 "[DebugInfo] DW_OP_deref_size in PrologEpilogInserter."Hans Wennborg2019-04-121-4/+0
| | | | | | | | | | | | | | | | | | | It causes clang to crash while building Chromium. See https://crbug.com/952230 for reproducer. > The PrologEpilogInserter need to insert a DW_OP_deref_size before > prepending a memory location expression to an already implicit > expression to avoid having the existing expression act on the memory > address instead of the value behind it. > > The reason for using DW_OP_deref_size and not plain DW_OP_deref is that > big-endian targets need to read the right size as simply truncating a > larger read would yield the wrong result (LSB bytes are not at the lower > address). > > Differential Revision: https://reviews.llvm.org/D59687 llvm-svn: 358281
* [DebugInfo] DW_OP_deref_size in PrologEpilogInserter.Markus Lavin2019-04-121-0/+4
| | | | | | | | | | | | | | | | The PrologEpilogInserter need to insert a DW_OP_deref_size before prepending a memory location expression to an already implicit expression to avoid having the existing expression act on the memory address instead of the value behind it. The reason for using DW_OP_deref_size and not plain DW_OP_deref is that big-endian targets need to read the right size as simply truncating a larger read would yield the wrong result (LSB bytes are not at the lower address). Differential Revision: https://reviews.llvm.org/D59687 llvm-svn: 358268
* Add explicit dependencies on MCSection.h and MCDwarf.h to the .cppEric Christopher2019-04-121-0/+1
| | | | | | files rather than rely on transitive includes from MCStreamer.h. llvm-svn: 358263
* [RISCV] Put data smaller than eight bytes to small data sectionShiva Chen2019-04-111-0/+3
| | | | | | | | | | | Because of gp = sdata_start_address + 0x800, gp with signed twelve-bit offset could covert most of the small data section. Linker relaxation could transfer the multiple data accessing instructions to a gp base with signed twelve-bit offset instruction. Differential Revision: https://reviews.llvm.org/D57493 llvm-svn: 358150
* [AsmPrinter] refactor to remove remove AsmVariant. NFCNick Desaulniers2019-04-101-22/+14
| | | | | | | | | | | | | | | | | | | | | | | | | Summary: The InlineAsm::AsmDialect is only required for X86; no architecture makes use of it and as such it gets passed around between arch-specific and general code while being unused for all architectures but X86. Since the AsmDialect is queried from a MachineInstr, which we also pass around, remove the additional AsmDialect parameter and query for it deep in the X86AsmPrinter only when needed/as late as possible. This refactor should help later planned refactors to AsmPrinter, as this difference in the X86AsmPrinter makes it harder to make AsmPrinter more generic. Reviewers: craig.topper Subscribers: jholewinski, arsenm, dschuff, jyknight, dylanmckay, sdardis, nemanjai, jvesely, nhaehnle, javed.absar, sbc100, jgravelle-google, eraman, hiraditya, aheejin, kbarton, fedor.sergeev, asb, rbar, johnrusso, simoncook, apazos, sabuasal, niosHD, jrtc27, zzheng, edward-jones, atanasyan, rogfer01, MartinMosbeck, brucehoult, the_o, PkmX, jocewei, jsji, llvm-commits, peter.smith, srhines Tags: #llvm Differential Revision: https://reviews.llvm.org/D60488 llvm-svn: 358101
* [DebugInfo] Track multiple registers in DbgEntityHistoryCalculatorDavid Stenberg2019-04-101-28/+41
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: When calculating the debug value history, DbgEntityHistoryCalculator would only keep track of register clobbering for the latest debug value per inlined entity. This meant that preceding register-described debug value fragments would live on until the next overlapping debug value, ignoring any potential clobbering. This patch amends DbgEntityHistoryCalculator so that it keeps track of all registers that a inlined entity's currently live debug values are described by. The DebugInfo/COFF/pieces.ll test case has had to be changed since previously a register-described fragment would incorrectly outlive its basic block. The parent patch D59941 is expected to increase the coverage slightly, as it makes sure that location list entries are inserted after clobbered fragments, and this patch is expected to decrease it, as it stops preceding register-described from living longer than they should. All in all, this patch and the preceding patch has a negligible effect on the output from `llvm-dwarfdump -statistics' for a clang-3.4 binary built using the RelWithDebInfo build profile. "Scope bytes covered" increases by 0.5%, and "variables with location" increases from 2212083 to 2212088, but it should improve the accuracy quite a bit. This fixes PR40283. Reviewers: aprantl, probinson, dblaikie, rnk, bjope Reviewed By: aprantl Subscribers: llvm-commits Tags: #debug-info, #llvm Differential Revision: https://reviews.llvm.org/D59942 llvm-svn: 358073
* [DebugInfo] Improve handling of clobbered fragmentsDavid Stenberg2019-04-104-106/+220
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Currently the DbgValueHistorymap only keeps track of clobbered registers for the last debug value that it has encountered. This could lead to preceding register-described debug values living on longer in the location lists than they should. See PR40283 for an example. This patch does not introduce tracking of multiple registers, but changes the DbgValueHistoryMap structure to allow for that in a follow-up patch. This patch is not NFC, as it at least fixes two bugs in DwarfDebug (both are covered in the new clobbered-fragments.mir test): * If a debug value was clobbered (its End pointer set), the value would still be added to OpenRanges, meaning that the succeeding location list entries could potentially contain stale values. * If a debug value was clobbered, and there were non-overlapping fragments that were still live after the clobbering, DwarfDebug would not create a location list entry starting directly after the clobbering instruction. This meant that the location list could have a gap until the next debug value for the variable was encountered. Before this patch, the history map was represented by <Begin, End> pairs, where a new pair was created for each new debug value. When dealing with partially overlapping register-described debug values, such as in the following example: DBG_VALUE $reg2, $noreg, !1, !DIExpression(DW_OP_LLVM_fragment, 32, 32) [...] DBG_VALUE $reg3, $noreg, !1, !DIExpression(DW_OP_LLVM_fragment, 64, 32) [...] $reg2 = insn1 [...] $reg3 = insn2 the history map would then contain the entries `[<DV1, insn1>, [<DV2, insn2>]`. This would leave it up to the users of the map to be aware of the relative order of the instructions, which e.g. could make DwarfDebug::buildLocationList() needlessly complex. Instead, this patch makes the history map structure monotonically increasing by dropping the End pointer, and replacing that with explicit clobbering entries in the vector. Each debug value has an "end index", which if set, points to the entry in the vector that ends the debug value. The ending entry can either be an overlapping debug value, or an instruction which clobbers the register that the debug value is described by. The ending entry's instruction can thus either be excluded or included in the debug value's range. If the end index is not set, the debug value that the entry introduces is valid until the end of the function. Changes to test cases: * DebugInfo/X86/pieces-3.ll: The range of the first DBG_VALUE, which describes that the fragment (0, 64) is located in RDI, was incorrectly ended by the clobbering of RAX, which the second (non-overlapping) DBG_VALUE was described by. With this patch we get a second entry that only describes RDI after that clobbering. * DebugInfo/ARM/partial-subreg.ll: This test seems to indiciate a bug in LiveDebugValues that is caused by it not being aware of fragments. I have added some comments in the test case about that. Also, before this patch DwarfDebug would incorrectly include a register-described debug value from a preceding block in a location list entry. Reviewers: aprantl, probinson, dblaikie, rnk, bjope Reviewed By: aprantl Subscribers: javed.absar, kristof.beyls, jdoerfert, llvm-commits Tags: #debug-info, #llvm Differential Revision: https://reviews.llvm.org/D59941 llvm-svn: 358072
* [AsmPrinter] Delete unused RangeSpanList::addRangeFangrui Song2019-04-101-1/+0
| | | | llvm-svn: 358068
* [DebugInfo] Rename DbgValueHistoryMap::{InstrRange -> Entry}, NFCDavid Stenberg2019-04-106-63/+60
| | | | | | | | | | | | | | | | | | | | | | | | | | Summary: In an upcoming commit the history map will be changed so that it contains explicit entries for instructions that clobber preceding debug values, rather than Begin- End range pairs, so generalize the name to "Entry". Also, prefix the iterator variable names in buildLocationList() with "E". In an upcoming commit the entry will have query functions such as "isD(e)b(u)gValue", which could at a glance make one confuse it for iterations over MachineInstrs, so make the iterator names a bit more distinct to avoid that. Reviewers: aprantl Reviewed By: aprantl Subscribers: llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D59939 llvm-svn: 358060
* [DebugInfo] Make InstrRange into a class, NFCDavid Stenberg2019-04-104-35/+41
| | | | | | | | | | | | | | | | | | | | Summary: Replace use of std::pair by creating a class for the debug value instruction ranges instead. This is a preparatory refactoring for improving handling of clobbered fragments. In an upcoming commit the Begin pointer will become a PointerIntPair, so it will be cleaner to have a getter for that. Reviewers: aprantl Subscribers: llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D59938 llvm-svn: 358059
* [DebugInfo] Pass all values in DebugLocEntry's constructor, NFCDavid Stenberg2019-04-092-24/+16
| | | | | | | | | | | | | | | | | | | | Summary: With MergeValues() removed, amend DebugLocEntry's constructor so that it takes multiple values rather than a single, and keep non-fragment values in OpenRanges, as this allows some cleanup of the code in buildLocationList(). Reviewers: aprantl, dblaikie, loladiro Reviewed By: aprantl Subscribers: hiraditya, llvm-commits Tags: #debug-info, #llvm Differential Revision: https://reviews.llvm.org/D59303 llvm-svn: 357988
* [DebugInfo] Remove redundant DebugLocEntry::MergeValues() function, NFCDavid Stenberg2019-04-092-56/+4
| | | | | | | | | | | | | | | | | | | | | | | Summary: The MergeValues() function would try to merge two entries if they shared the same beginning label. Having the same beginning label means that the former entry's range would be empty; however, after D55919 we no longer create entries for empty ranges, so we can no longer land in a situation where that check in MergeValues would succeed. Instead, the "merging" is done by keeping the live values from the preceding empty ranges in OpenRanges, and adding them to the first non-empty range. Reviewers: aprantl, dblaikie, loladiro Reviewed By: aprantl Subscribers: llvm-commits Tags: #debug-info, #llvm Differential Revision: https://reviews.llvm.org/D59301 llvm-svn: 357974
* Add LLVM IR debug info support for Fortran COMMON blocksAdrian Prantl2019-04-083-3/+35
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | COMMON blocks are a feature of Fortran that has no direct analog in C languages, but they are similar to data sections in assembly language programming. A COMMON block is a named area of memory that holds a collection of variables. Fortran subprograms may map the COMMON block memory area to their own, possibly distinct, non-empty list of variables. A Fortran COMMON block might look like the following example. COMMON /ALPHA/ I, J For this construct, the compiler generates a new scope-like DI construct (!DICommonBlock) into which variables (see I, J above) can be placed. As the common block implies a range of storage with global lifetime, the !DICommonBlock refers to a !DIGlobalVariable. The Fortran variable that comprise the COMMON block are also linked via metadata to offsets within the global variable that stands for the entire common block. @alpha_ = common global %alphabytes_ zeroinitializer, align 64, !dbg !27, !dbg !30, !dbg !33 !14 = distinct !DISubprogram(…) !20 = distinct !DICommonBlock(scope: !14, declaration: !25, name: "alpha") !25 = distinct !DIGlobalVariable(scope: !20, name: "common alpha", type: !24) !27 = !DIGlobalVariableExpression(var: !25, expr: !DIExpression()) !29 = distinct !DIGlobalVariable(scope: !20, name: "i", file: !3, type: !28) !30 = !DIGlobalVariableExpression(var: !29, expr: !DIExpression()) !31 = distinct !DIGlobalVariable(scope: !20, name: "j", file: !3, type: !28) !32 = !DIExpression(DW_OP_plus_uconst, 4) !33 = !DIGlobalVariableExpression(var: !31, expr: !32) The DWARF generated for this is as follows. DW_TAG_common_block: DW_AT_name: alpha DW_AT_location: @alpha_+0 DW_TAG_variable: DW_AT_name: common alpha DW_AT_type: array of 8 bytes DW_AT_location: @alpha_+0 DW_TAG_variable: DW_AT_name: i DW_AT_type: integer*4 DW_AT_location: @Alpha+0 DW_TAG_variable: DW_AT_name: j DW_AT_type: integer*4 DW_AT_location: @Alpha+4 Patch by Eric Schweitz! Differential Revision: https://reviews.llvm.org/D54327 llvm-svn: 357934
* Change some dyn_cast to more apropriate isa. NFCFangrui Song2019-04-051-1/+1
| | | | llvm-svn: 357773
* NFC: Move API uses of MD5::MD5Result to Optional rather than a pointer.Eric Christopher2019-04-043-8/+8
| | | | | | Differential Revision: https://reviews.llvm.org/D60290 llvm-svn: 357736
* [IR] Refactor attribute methods in Function class (NFC)Evandro Menezes2019-04-042-2/+2
| | | | | | | | Rename the functions that query the optimization kind attributes. Differential revision: https://reviews.llvm.org/D60287 llvm-svn: 357731
* [IR] Create new method in `Function` class (NFC)Evandro Menezes2019-04-031-2/+2
| | | | | | | | | Create method `optForNone()` testing for the function level equivalent of `-O0` and refactor appropriately. Differential revision: https://reviews.llvm.org/D59852 llvm-svn: 357638
* [RISCV] Generate address sequences suitable for mcmodel=mediumAlex Bradbury2019-04-011-1/+4
| | | | | | | | | | | | | | | | | This patch adds an implementation of a PC-relative addressing sequence to be used when -mcmodel=medium is specified. With absolute addressing, a 'medium' codemodel may cause addresses to be out of range. This is because while 'medium' implies a 2 GiB addressing range, this 2 GiB can be at any offset as opposed to 'small', which implies the first 2 GiB only. Note that LLVM/Clang currently specifies code models differently to GCC, where small and medium imply the same functionality as GCC's medlow and medany respectively. Differential Revision: https://reviews.llvm.org/D54143 Patch by Lewis Revill. llvm-svn: 357393
* [Remarks] Emit a section containing remark diagnostics metadataFrancis Visoiu Mistrih2019-03-271-0/+45
| | | | | | | | | | | | | | | | A section containing metadata on remark diagnostics will be emitted if the flag (-mllvm) -remarks-section is present. For now, the metadata is: * a magic number for remarks: "REMARKS\0" * the version number: a little-endian uint64_t * the absolute file path to the serialized remark diagnostics: a null-terminated string. Differential Revision: https://reviews.llvm.org/D59571 llvm-svn: 357043
* Revert "[llvm] Reapply "Prevent duplicate files in debug line header in ↵Ali Tamur2019-03-263-2/+1
| | | | | | | | | | | | | dwarf 5."" This reverts commit rL357020. The commit broke the test llvm/test/tools/llvm-objdump/embedded-source.test on some builds including clang-ppc64be-linux-multistage, clang-s390x-linux, clang-with-lto-ubuntu, clang-x64-windows-msvc, llvm-clang-lld-x86_64-scei-ps4-windows10pro-fast (and others). llvm-svn: 357026
* [llvm] Reapply "Prevent duplicate files in debug line header in dwarf 5."Ali Tamur2019-03-263-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Reapply rL356941 after regenerating the object file in the failing test llvm/test/tools/llvm-objdump/embedded-source.test from source. Original commit message: [llvm] Prevent duplicate files in debug line header in dwarf 5. Motivation: In previous dwarf versions, file name indexes started from 1, and the primary source file was not explicit. Dwarf 5 standard (6.2.4) prescribes the primary source file to be explicitly given an entry with an index number 0. The current implementation honors the specification by just duplicating the main source file, once with index number 0, and later maybe with another index number. While this is compliant with the letter of the standard, the duplication causes problems for consumers of this information such as lldb. (Some files are duplicated, where only some of them have a line table although all refer to the same file) With this change, dwarf 5 debug line section files always start from 0, and the zeroth entry is not duplicated whenever possible. This requires different handling of dwarf 4 and dwarf 5 during generation (e.g. when a function returns an index zero for a file name, it signals an error in dwarf 4, but not in dwarf 5) However, I think the minor complication is worth it, because it enables all consumers (lldb, gdb, dwarfdump, objdump, and so on) to treat all files in the file name list homogenously. Tags: #llvm, #debug-info Differential Revision: https://reviews.llvm.org/D59515 llvm-svn: 357018
* Revert "[llvm] Prevent duplicate files in debug line header in dwarf 5."Ali Tamur2019-03-253-2/+1
| | | | | | | | This reverts commit 312ab05887d0e2caa29aaf843cefe39379a98d36. My commit broke the build; I will revert and find out what happened. llvm-svn: 356951
* [llvm] Prevent duplicate files in debug line header in dwarf 5.Ali Tamur2019-03-253-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Motivation: In previous dwarf versions, file name indexes started from 1, and the primary source file was not explicit. Dwarf 5 standard (6.2.4) prescribes the primary source file to be explicitly given an entry with an index number 0. The current implementation honors the specification by just duplicating the main source file, once with index number 0, and later maybe with another index number. While this is compliant with the letter of the standard, the duplication causes problems for consumers of this information such as lldb. (Some files are duplicated, where only some of them have a line table although all refer to the same file) With this change, dwarf 5 debug line section files always start from 0, and the zeroth entry is not duplicated whenever possible. This requires different handling of dwarf 4 and dwarf 5 during generation (e.g. when a function returns an index zero for a file name, it signals an error in dwarf 4, but not in dwarf 5) However, I think the minor complication is worth it, because it enables all consumers (lldb, gdb, dwarfdump, objdump, and so on) to treat all files in the file name list homogenously. Reviewers: dblaikie, probinson, aprantl, espindola Reviewed By: probinson Subscribers: emaste, jvesely, nhaehnle, aprantl, javed.absar, arichardson, hiraditya, MaskRay, rupprecht, jdoerfert, llvm-commits Tags: #llvm, #debug-info Differential Revision: https://reviews.llvm.org/D59515 llvm-svn: 356941
* [DwarfDebug] Skip entries to big for 16 bit size field in Dwarf < 5.Florian Hahn2019-03-191-1/+7
| | | | | | | | | | | | | | | | Nothing prevents entries from being bigger than the 16 bit size field in Dwarf < 5. For entries that are too big, just emit an empty entry instead of crashing. This fixes PR41038. Reviewers: probinson, aprantl, davide Reviewed By: probinson Differential Revision: https://reviews.llvm.org/D59518 llvm-svn: 356514
* [DebugInfo] Introduce DW_OP_LLVM_convertMarkus Lavin2019-03-1914-37/+230
| | | | | | | | | | | | | | | | | | | | | Introduce a DW_OP_LLVM_convert Dwarf expression pseudo op that allows for a convenient way to perform type conversions on the Dwarf expression stack. As an additional bonus it paves the way for using other Dwarf v5 ops that need to reference a base_type. The new DW_OP_LLVM_convert is used from lib/Transforms/Utils/Local.cpp to perform sext/zext on debug values but mainly the patch is about preparing terrain for adding other Dwarf v5 ops that need to reference a base_type. For Dwarf v5 the op maps to DW_OP_convert and for earlier versions a complex shift & mask pattern is generated to emulate sext/zext. This is a recommit of r356442 with trivial fixes for the failing tests. Differential Revision: https://reviews.llvm.org/D56587 llvm-svn: 356451
* Revert "[DebugInfo] Introduce DW_OP_LLVM_convert"Markus Lavin2019-03-1914-229/+37
| | | | | | | | | | | | | This reverts commit 1cf4b593a7ebd666fc6775f3bd38196e8e65fafe. Build bots found failing tests not detected locally. Failing Tests (3): LLVM :: DebugInfo/Generic/convert-debugloc.ll LLVM :: DebugInfo/Generic/convert-inlined.ll LLVM :: DebugInfo/Generic/convert-linked.ll llvm-svn: 356444
* [DebugInfo] Introduce DW_OP_LLVM_convertMarkus Lavin2019-03-1914-37/+229
| | | | | | | | | | | | | | | | | | | Introduce a DW_OP_LLVM_convert Dwarf expression pseudo op that allows for a convenient way to perform type conversions on the Dwarf expression stack. As an additional bonus it paves the way for using other Dwarf v5 ops that need to reference a base_type. The new DW_OP_LLVM_convert is used from lib/Transforms/Utils/Local.cpp to perform sext/zext on debug values but mainly the patch is about preparing terrain for adding other Dwarf v5 ops that need to reference a base_type. For Dwarf v5 the op maps to DW_OP_convert and for earlier versions a complex shift & mask pattern is generated to emulate sext/zext. Differential Revision: https://reviews.llvm.org/D56587 llvm-svn: 356442
* Add IR debug info support for Elemental, Pure, and Recursive Procedures.Adrian Prantl2019-03-141-0/+6
| | | | | | | | Patch by Eric Schweitz! Differential Revision: https://reviews.llvm.org/D54043 llvm-svn: 356163
* Add Swift enumerator value for CodeView::SourceLanguageNathan Lanza2019-03-111-0/+2
| | | | | | | | | | | | | | | Summary: Swift now generates PDBs for debugging on Windows. llvm and lldb need a language enumerator value too properly handle the output emitted by swiftc. Subscribers: jdoerfert, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D59231 llvm-svn: 355882
* Remove ASan asm instrumentation.Evgeniy Stepanov2019-03-111-10/+1
| | | | | | | | | | | | | | Summary: It is incomplete and has no users AFAIK. Reviewers: pcc, vitalybuka Subscribers: srhines, kubamracek, mgorny, krytarowski, eraman, hiraditya, jdoerfert, #sanitizers, llvm-commits, thakis Tags: #sanitizers, #llvm Differential Revision: https://reviews.llvm.org/D59154 llvm-svn: 355870
* Revert "[Remarks] Refactor remark diagnostic emission in a RemarkStreamer"Francis Visoiu Mistrih2019-03-061-1/+0
| | | | | | | | This reverts commit 2e8c4997a2089f8228c843fd81b148d903472e02. Breaks bots. llvm-svn: 355511
* [Remarks] Refactor remark diagnostic emission in a RemarkStreamerFrancis Visoiu Mistrih2019-03-061-0/+1
| | | | | | | | | | This allows us to store more info about where we're emitting the remarks without cluttering LLVMContext. This is needed for future support for the remark section. Differential Revision: https://reviews.llvm.org/D58996 llvm-svn: 355507
* [DebugInfo] Construct nested types on behalf of owner CUEugene Leviant2019-03-042-22/+31
| | | | | | Differential revision: https://reviews.llvm.org/D58786 llvm-svn: 355303
* [DebugInfo] Apply subprogram attributes on behalf of owner CUEugene Leviant2019-02-272-2/+3
| | | | | | | | | | | | When using full LTO it is possible that template function definition DIE is bound to one compilation unit and it's declaration to another. We should add function declaration attributes on behalf of its owner CU otherwise we may end up with malformed file identifier in function declaration DW_AT_decl_file attribute. Differential revision: https://reviews.llvm.org/D58538 llvm-svn: 354978
* [CodeView] Emit HasConstructorOrDestructor class option for non-trivial ↵Aaron Smith2019-02-261-4/+12
| | | | | | | | | | | | | | | | constructors Reviewers: zturner, rnk, llvm-commits, aleksandr.urakov Reviewed By: zturner, rnk Subscribers: jdoerfert, majnemer, asmith Tags: #llvm Differential Revision: https://reviews.llvm.org/D44406 llvm-svn: 354841
* [DebugInfo] Stop changing labels for register-described parameter DBG_VALUEsDavid Stenberg2019-02-131-7/+19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This is a follow-up to D57510. This patch stops DebugHandlerBase from changing the starting label for the first non-overlapping, register-described parameter DBG_VALUEs to the beginning of the function. That code did not consider what defined the registers, which could result in the ranges for the debug values starting before their defining instructions. We currently do not emit debug values for constant values directly at the start of the function, so this code is still useful for such values, but my intention is to remove the code from DebugHandlerBase completely when we get there. One reason for removing it is that the code violates the history map's ranges, which I think can make it quite confusing when troubleshooting. In D57510, PrologEpilogInserter was amended so that parameter DBG_VALUEs now are kept at the start of the entry block, even after emission of prologue code. That was done to reduce the degradation of debug completeness from this patch. PR40638 is another example, where the lexical-scope trimming that LDV does, in combination with scheduling, results in instructions after the prologue being left without locations. There might be other cases where the DBG_VALUEs are pushed further down, for which the DebugHandlerBase code may be helpful, but as it now quite often result in incorrect locations, even after the prologue, it seems better to remove that code, and try to work our way up with accurate locations. In the long run we should maybe not aim to provide accurate locations inside the prologue. Some single location descriptions, at least those referring to stack values, generate inaccurate values inside the epilogue, so we maybe should not aim to achieve accuracy for location lists. However, it seems that we now emit line number programs that can result in GDB and LLDB stopping inside the prologue when doing line number stepping into functions. See PR40188 for more information. A summary of some of the changed test cases is available in PR40188#c2. Reviewers: aprantl, dblaikie, rnk, jmorse Reviewed By: aprantl Subscribers: jdoerfert, jholewinski, jvesely, javed.absar, llvm-commits Tags: #debug-info, #llvm Differential Revision: https://reviews.llvm.org/D57511 llvm-svn: 353928
* DebugInfo: Split DWARF + gmlt + no-split-dwarf-inlining shouldn't emit ↵David Blaikie2019-02-122-2/+12
| | | | | | | | | | | | | | | anything to the .dwo file This configuration (due to r349207) was intended not to emit any DWO CU, but a degenerate CU was still being emitted - containing a header and a DW_TAG_compile_unit with no attributes. Under that situation, emit nothing to the .dwo file. (since this is a dynamic property of the input the .dwo file is still emitted, just with nothing in it (so a valid, but empty, ELF file) - if some other CU didn't satisfy this criteria, its DWO CU would still go there, etc) llvm-svn: 353771
* Implementation of asm-goto support in LLVMCraig Topper2019-02-082-3/+11
| | | | | | | | | | | | | | | | | | | | | | | | | This patch accompanies the RFC posted here: http://lists.llvm.org/pipermail/llvm-dev/2018-October/127239.html This patch adds a new CallBr IR instruction to support asm-goto inline assembly like gcc as used by the linux kernel. This instruction is both a call instruction and a terminator instruction with multiple successors. Only inline assembly usage is supported today. This also adds a new INLINEASM_BR opcode to SelectionDAG and MachineIR to represent an INLINEASM block that is also considered a terminator instruction. There will likely be more bug fixes and optimizations to follow this, but we felt it had reached a point where we would like to switch to an incremental development model. Patch by Craig Topper, Alexander Ivchenko, Mikhail Dvoretckii Differential Revision: https://reviews.llvm.org/D53765 llvm-svn: 353563
* Remove reference to non-existent function. NFC.Sam Clegg2019-02-071-2/+1
| | | | | | | | This comment is old. The code in question was removed in rL203174 Differential Revision: https://reviews.llvm.org/D57856 llvm-svn: 353352
* [DEBUG_INFO][NVPTX] Generate DW_AT_address_class to get the values in debugger.Alexey Bataev2019-02-051-2/+54
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: According to https://docs.nvidia.com/cuda/archive/10.0/ptx-writers-guide-to-interoperability/index.html#cuda-specific-dwarf, the compiler should emit the DW_AT_address_class attribute for all variable and parameter. It means, that DW_AT_address_class attribute should be used in the non-standard way to support compatibility with the cuda-gdb debugger. Clang is able to generate the information about the variable address class. This information is emitted as the expression sequence `DW_OP_constu <DWARF Address Space> DW_OP_swap DW_OP_xderef`. The patch tries to find all such expressions and transform them into `DW_AT_address_class <DWARF Address Space>` if target is NVPTX and the debugger is gdb. If the expression is not found, then default values are used. For the local variables <DWARF Address Space> is set to ADDR_local_space(6), for the globals <DWARF Address Space> is set to ADDR_global_space(5). The values are taken from the table in the same section 5.2. CUDA-Specific DWARF Definitions. Reviewers: echristo, probinson Subscribers: jholewinski, aprantl, llvm-commits Differential Revision: https://reviews.llvm.org/D57157 llvm-svn: 353203
* [WebAssembly] MC: Mark more function aliases as functionsSam Clegg2019-02-041-1/+11
| | | | | | | | | | | | | Aliases of functions are now marked as function symbols even if they are bitcast to some other other non-function type. This is important for WebAssembly where object and function symbols can't alias each other. Fixes PR38866 Differential Revision: https://reviews.llvm.org/D57538 llvm-svn: 353109
* [DEBUGINFO] Reposting r352642: Handle restore instructions in LiveDebugValuesWolfgang Pieb2019-02-041-32/+11
| | | | | | | | | | | | | | | | | The LiveDebugValues pass recognizes spills but not restores, which can cause large gaps in location information for some variables, depending on control flow. This patch make LiveDebugValues recognize restores and generate appropriate DBG_VALUE instructions. This patch was posted previously with r352642 and reverted in r352666 due to buildbot errors. A missing return statement was the cause for the failures. Reviewers: aprantl, NicolaPrica Differential Revision: https://reviews.llvm.org/D57271 llvm-svn: 353089
* [AsmPrinter] Remove hidden flag -print-schedule.Andrea Di Biagio2019-02-042-48/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch removes hidden codegen flag -print-schedule effectively reverting the logic originally committed as r300311 (https://llvm.org/viewvc/llvm-project?view=revision&revision=300311). Flag -print-schedule was originally introduced by r300311 to address PR32216 (https://bugs.llvm.org/show_bug.cgi?id=32216). That bug was about adding "Better testing of schedule model instruction latencies/throughputs". These days, we can use llvm-mca to test scheduling models. So there is no longer a need for flag -print-schedule in LLVM. The main use case for PR32216 is now addressed by llvm-mca. Flag -print-schedule is mainly used for debugging purposes, and it is only actually used by x86 specific tests. We already have extensive (latency and throughput) tests under "test/tools/llvm-mca" for X86 processor models. That means, most (if not all) existing -print-schedule tests for X86 are redundant. When flag -print-schedule was first added to LLVM, several files had to be modified; a few APIs gained new arguments (see for example method MCAsmStreamer::EmitInstruction), and MCSubtargetInfo/TargetSubtargetInfo gained a couple of getSchedInfoStr() methods. Method getSchedInfoStr() had to originally work for both MCInst and MachineInstr. The original implmentation of getSchedInfoStr() introduced a subtle layering violation (reported as PR37160 and then fixed/worked-around by r330615). In retrospect, that new API could have been designed more optimally. We can always query MCSchedModel to get the latency and throughput. More importantly, the "sched-info" string should not have been generated by the subtarget. Note, r317782 fixed an issue where "print-schedule" didn't work very well in the presence of inline assembly. That commit is also reverted by this change. Differential Revision: https://reviews.llvm.org/D57244 llvm-svn: 353043
OpenPOWER on IntegriCloud