summaryrefslogtreecommitdiffstats
path: root/llvm/test/DebugInfo/Generic
Commit message (Collapse)AuthorAgeFilesLines
...
* [DEBUGINFO] Disable emission of the dwarf sections, but allow directives.Alexey Bataev2018-08-011-0/+59
| | | | | | | | | | | | | | | | Summary: Added an option that allows to emit only '.loc' and '.file' kind debug directives, but disables emission of the DWARF sections. Required for NVPTX target to support profiling. It requires '.loc' and '.file' directives, but does not require any DWARF sections for the profiler. Reviewers: probinson, echristo, dblaikie Subscribers: aprantl, JDevlieghere, llvm-commits Differential Revision: https://reviews.llvm.org/D46021 llvm-svn: 338616
* Revert "[DebugInfo] Generate DWARF debug information for labels."Vlad Tsyrklevich2018-07-312-134/+0
| | | | | | | This reverts commits r338390 and r338398, they were causing LSan failures on the ASan bot. llvm-svn: 338408
* [DebugInfo] Fix build failed in 'clang-cmake-armv8-full'.Hsiangkai Wang2018-07-311-8/+16
| | | | | | | | Builder clang-cmake-armv8-full failed due to the assembly 'comment' notation is not '#' in the target. So, I use CHECK-SAME to avoid to check the comment notation in the same line in the test case. llvm-svn: 338398
* [DebugInfo] Generate DWARF debug information for labels.Hsiangkai Wang2018-07-312-0/+126
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | There are two forms for label debug information in DWARF format. 1. Labels in a non-inlined function: DW_TAG_label DW_AT_name DW_AT_decl_file DW_AT_decl_line DW_AT_low_pc 2. Labels in an inlined function: DW_TAG_label DW_AT_abstract_origin DW_AT_low_pc We will collect label information from DBG_LABEL. Before every DBG_LABEL, we will generate a temporary symbol to denote the location of the label. The symbol could be used to get DW_AT_low_pc afterwards. So, we create a mapping between 'inlined label' and DBG_LABEL MachineInstr in DebugHandlerBase. The DBG_LABEL in the mapping is used to query the symbol before it. The AbstractLabels in DwarfCompileUnit is used to process labels in inlined functions. We also keep a mapping between scope and labels in DwarfFile to help to generate correct tree structure of DIEs. It also generates label debug information under global isel. Differential Revision: https://reviews.llvm.org/D45556 llvm-svn: 338390
* Revert "[DebugInfo] Generate DWARF debug information for labels."Shiva Chen2018-07-242-126/+0
| | | | | | This reverts commit b454fa1b4079b6c0a5b1565982d16516385838d7. llvm-svn: 337812
* [DebugInfo] Generate DWARF debug information for labels.Shiva Chen2018-07-242-0/+126
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | There are two forms for label debug information in DWARF format. 1. Labels in a non-inlined function: DW_TAG_label DW_AT_name DW_AT_decl_file DW_AT_decl_line DW_AT_low_pc 2. Labels in an inlined function: DW_TAG_label DW_AT_abstract_origin DW_AT_low_pc We will collect label information from DBG_LABEL. Before every DBG_LABEL, we will generate a temporary symbol to denote the location of the label. The symbol could be used to get DW_AT_low_pc afterwards. So, we create a mapping between 'inlined label' and DBG_LABEL MachineInstr in DebugHandlerBase. The DBG_LABEL in the mapping is used to query the symbol before it. The AbstractLabels in DwarfCompileUnit is used to process labels in inlined functions. We also keep a mapping between scope and labels in DwarfFile to help to generate correct tree structure of DIEs. Differential Revision: https://reviews.llvm.org/D45556 Patch by Hsiangkai Wang. llvm-svn: 337799
* Rename __asan_gen_* symbols to ___asan_gen_*.Peter Collingbourne2018-07-181-4/+4
| | | | | | | | | | This prevents gold from printing a warning when trying to export these symbols via the asan dynamic list after ThinLTO promotes them from private symbols to external symbols with hidden visibility. Differential Revision: https://reviews.llvm.org/D49498 llvm-svn: 337428
* [DebugInfo] Fix PR37395.Shiva Chen2018-07-031-0/+63
| | | | | | | | | | DbgLabelInst has no address as its operands. Differential Revision: https://reviews.llvm.org/D46738 Patch by Hsiangkai Wang. llvm-svn: 336176
* [SelectionDAG] Remove debug locations from ConstantSD(FP)NodesVedant Kumar2018-06-252-48/+0
| | | | | | | | | | | | | | | | | | This removes debug locations from ConstantSDNode and ConstantSDFPNode. When this kind of node is materialized we no longer create a line table entry which jumps back to the constant's first point of use. This makes single-stepping behavior smoother, and it matches the model used by IR, where Constants have no locations. See this thread for more context: http://lists.llvm.org/pipermail/llvm-dev/2018-June/124164.html I'd like to handle constant BuildVectorSDNodes and to try to eliminate passing SDLocs to SelectionDAG::getConstant*() in follow-up commits. Differential Revision: https://reviews.llvm.org/D48468 llvm-svn: 335497
* Generalize MergeBlockIntoPredecessor. Replace uses of ↵Alina Sbirlea2018-06-201-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | MergeBasicBlockIntoOnlyPred. Summary: Two utils methods have essentially the same functionality. This is an attempt to merge them into one. 1. lib/Transforms/Utils/Local.cpp : MergeBasicBlockIntoOnlyPred 2. lib/Transforms/Utils/BasicBlockUtils.cpp : MergeBlockIntoPredecessor Prior to the patch: 1. MergeBasicBlockIntoOnlyPred Updates either DomTree or DeferredDominance Moves all instructions from Pred to BB, deletes Pred Asserts BB has single predecessor If address was taken, replace the block address with constant 1 (?) 2. MergeBlockIntoPredecessor Updates DomTree, LoopInfo and MemoryDependenceResults Moves all instruction from BB to Pred, deletes BB Returns if doesn't have a single predecessor Returns if BB's address was taken After the patch: Method 2. MergeBlockIntoPredecessor is attempting to become the new default: Updates DomTree or DeferredDominance, and LoopInfo and MemoryDependenceResults Moves all instruction from BB to Pred, deletes BB Returns if doesn't have a single predecessor Returns if BB's address was taken Uses of MergeBasicBlockIntoOnlyPred that need to be replaced: 1. lib/Transforms/Scalar/LoopSimplifyCFG.cpp Updated in this patch. No challenges. 2. lib/CodeGen/CodeGenPrepare.cpp Updated in this patch. i. eliminateFallThrough is straightforward, but I added using a temporary array to avoid the iterator invalidation. ii. eliminateMostlyEmptyBlock(s) methods also now use a temporary array for blocks Some interesting aspects: - Since Pred is not deleted (BB is), the entry block does not need updating. - The entry block was being updated with the deleted block in eliminateMostlyEmptyBlock. Added assert to make obvious that BB=SinglePred. - isMergingEmptyBlockProfitable assumes BB is the one to be deleted. - eliminateMostlyEmptyBlock(BB) does not delete BB on one path, it deletes its unique predecessor instead. - adding some test owner as subscribers for the interesting tests modified: test/CodeGen/X86/avx-cmp.ll test/CodeGen/AMDGPU/nested-loop-conditions.ll test/CodeGen/AMDGPU/si-annotate-cf.ll test/CodeGen/X86/hoist-spill.ll test/CodeGen/X86/2006-11-17-IllegalMove.ll 3. lib/Transforms/Scalar/JumpThreading.cpp Not covered in this patch. It is the only use case using the DeferredDominance. I would defer to Brian Rzycki to make this replacement. Reviewers: chandlerc, spatel, davide, brzycki, bkramer, javed.absar Subscribers: qcolombet, sanjoy, nemanjai, nhaehnle, jlebar, tpr, kbarton, RKSimon, wmi, arsenm, llvm-commits Differential Revision: https://reviews.llvm.org/D48202 llvm-svn: 335183
* [CodeGen/AccelTable]: Handle -dwarf-linkage-names=Abstract correctlyPavel Labath2018-05-142-1/+89
| | | | | | | | | | | | | | | | | | | | Summary: If we are not emitting a linkage name in the .debug_info sections, we should not add it into the index either. This makes sure our index is consistent with the actual debug info. I am also explicitly setting the --dwarf-linkage-names=All in the name-collsions test as that one would now fail on targets where this defaults to "Abstract" (in fact, it would have failed already if there wasn't a bug in the DWARF verifier, which I fix as well). Reviewers: probinson, aprantl, JDevlieghere Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D46748 llvm-svn: 332246
* [DebugInfo] Mark tests using -debug-only as REQUIRES: assertsBenjamin Kramer2018-05-092-0/+2
| | | | llvm-svn: 331865
* [DebugInfo] Fix test failed due to debug-label-mi.ll and debug-label-opt.llShiva Chen2018-05-092-17/+13
| | | | | | | | | | Make these two test cases more generic for other architectures. Please refer to '[DebugInfo] Convert intrinsic llvm.dbg.label to MachineInstr.' Patch by Hsiangkai Wang llvm-svn: 331853
* [DebugInfo] Convert intrinsic llvm.dbg.label to MachineInstr.Shiva Chen2018-05-092-0/+131
| | | | | | | | | | | | | | | | | | | | | In order to convert LLVM IR to MachineInstr, we need a new TargetOpcode, DBG_LABEL, to ‘lower’ intrinsic llvm.dbg.label. The patch creates this new TargetOpcode and convert intrinsic llvm.dbg.label to MachineInstr through SelectionDAG. In SelectionDAG, debug information is stored in SDDbgInfo. We create a new data member of SDDbgInfo for labels and use the new data member, SDDbgLabel, to create DBG_LABEL MachineInstr. The new DBG_LABEL MachineInstr uses label metadata from LLVM IR as its parameter. So, the backend could get metadata information of labels from DBG_LABEL MachineInstr. Differential Revision: https://reviews.llvm.org/D45341 Patch by Hsiangkai Wang. llvm-svn: 331842
* [DebugInfo] Add DILabel metadata and intrinsic llvm.dbg.label.Shiva Chen2018-05-0977-140/+140
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In order to set breakpoints on labels and list source code around labels, we need collect debug information for labels, i.e., label name, the function label belong, line number in the file, and the address label located. In order to keep these information in LLVM IR and to allow backend to generate debug information correctly. We create a new kind of metadata for labels, DILabel. The format of DILabel is !DILabel(scope: !1, name: "foo", file: !2, line: 3) We hope to keep debug information as much as possible even the code is optimized. So, we create a new kind of intrinsic for label metadata to avoid the metadata is eliminated with basic block. The intrinsic will keep existing if we keep it from optimized out. The format of the intrinsic is llvm.dbg.label(metadata !1) It has only one argument, that is the DILabel metadata. The intrinsic will follow the label immediately. Backend could get the label metadata through the intrinsic's parameter. We also create DIBuilder API for labels to be used by Frontend. Frontend could use createLabel() to allocate DILabel objects, and use insertLabel() to insert llvm.dbg.label intrinsic in LLVM IR. Differential Revision: https://reviews.llvm.org/D45024 Patch by Hsiangkai Wang. llvm-svn: 331841
* Fix macosx build broken by r330249Pavel Labath2018-04-181-4/+0
| | | | | | | | | | | | | It seems llc crashes when targetting darwin with split-dwarf (pr37164). This happens on all inputs, not just the one I added in the above commit. Work around the issue by hardcoding the target triple to linux, which is what all split-dwarf tests seem to be doing. As I don't know of a way to specify the os part of the triple without spelling out the architecture as well, I move the new test to the X86 folder. llvm-svn: 330265
* [CodeGen/Dwarf] Make debug_names compatible with split-dwarfPavel Labath2018-04-181-0/+4
| | | | | | | | | | | | | | | | | | Summary: Previously we crashed for the combination of the two features because we tried to reference the dwo CU from the main object file. The fix consists of two items: - reference the skeleton CU from the name index (the consumer is expected to use the skeleton CU to find the real data). - use the main object file string pool for the strings in the index Reviewers: JDevlieghere, aprantl, dblaikie Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D45566 llvm-svn: 330249
* [DebugInfo] Follow-up bug fix on "Fixing a couple of DI duplication bugs of ↵Roman Tereshin2018-04-161-0/+41
| | | | | | | | | | | | CloneModule" Apparently, DebugInfoFinder::processCompileUnit doesn't process all of the possible kinds of DIImportedEntit'ies, e.g. DIGlobalVariable's. Previously introduced `llvm_unreachable` is therefore incorrect. Removing it here. llvm-svn: 330167
* [DebugInfo] Create merged locations for instructions other than callsVedant Kumar2018-04-123-23/+28
| | | | | | | | | | | | | | | | | | This lifts a restriction on DILocation::getMergedLocation(), allowing it to create merged locations for instructions other than calls. Instruction::applyMergedLocation() now defaults to creating merged locations for all instructions. The default behavior of getMergedLocation() is unchanged: callers which invoke it directly are unaffected. This change will enable a follow-up Mem2Reg fix which improves crash reporting. Differential Revision: https://reviews.llvm.org/D45396 llvm-svn: 329955
* [CodeGen/Dwarf] Rename the "sizetype" synthetic type and add it to the ↵Pavel Labath2018-04-101-0/+38
| | | | | | | | | | | | | | | | | | | | | | | | accelerator table Summary: This type is created on-demand and used as the base type for array ranges. Since it is "special", its construction did not go through the createTypeDIE function and so it was never inserted into the accelerator table, although it clearly belongs there. I add an explicit addAccelType call to insert it into the table. During review, we also decided to rename the type to something more unique to avoid confusion in case the user has own "sizetype" type. The new name for the type size __ARRAY_SIZE_TYPE__. Reviewers: JDevlieghere, aprantl, dblaikie Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D45445 llvm-svn: 329705
* [CodeGen/AccelTable] Don't emit zero-CU name indexesPavel Labath2018-04-091-0/+19
| | | | | | | | | | | | | | | | | Summary: If an input DICompileUnit is completely empty (e.g., the result of running "clang -g" on an empty file), we don't bother emitting an empty DWARF CU. When we do that, we must make sure we don't also emit a DWARF v5 name index, as DWARF specifies that each index must reference at least one compilation unit. Reviewers: JDevlieghere, aprantl, dblaikie Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D45435 llvm-svn: 329575
* Make the test case from r329552 more portablePavel Labath2018-04-091-2/+2
| | | | | | | | | | - when tuning for SCE debugger (default for ps4 targets), we will not emit the DW_AT_linkage_name, which this test needs. I explicitly set the debugger tuning parameter to get the attribute always. - darwin targets did not like the "section .text.startup" fragment of the test. This is not actually needed for the test, so I remove it. llvm-svn: 329555
* [CodeGen/AccelTable]: Don't emit accelerator entries for functions with no namesPavel Labath2018-04-091-0/+38
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: We were emitting accelerator entries for functions with no name, which is contrary to the DWARF v5 spec: "All other (i.e., *not* DW_TAG_namespace) debugging information entries without a DW_AT_name attribute are excluded." Besides that, a name table entry with an empty string as a key is fairly useless. We can sometimes end up with functions which have a DW_AT_linkage_name but no DW_AT_name. One such example is the global-constructor-initialization functions, which C++ compilers synthesize for each compilation unit with global constructors. A very strict reading of the DWARF v5 spec would suggest that we should not even emit the accelerator entry for the linkage name in this case, but I don't think we should go that far. I found this when running the dwarf verifier over llvm codebase compiled with DWARF v5 accelerator tables. Reviewers: JDevlieghere, aprantl, dblaikie Subscribers: vleschuk, clayborg, echristo, probinson, llvm-commits Differential Revision: https://reviews.llvm.org/D45367 llvm-svn: 329552
* Re-commit r329179 after fixing build&test issuesPavel Labath2018-04-047-2/+1875
| | | | | | | | | | | - MSVC was not OK with a static_assert referencing a non-static member variable, even though it was just in a sizeof(expression). I move the assert into the emit function, where it is probably more useful. - Tests were failing in builds which did not have the X86 target configured. Since this functionality is not target-specific, I have removed the target specifiers from the .ll files. llvm-svn: 329201
* Revert r329179 (and follow-up unsuccessful fix attempts 329184, 329186); it ↵Nico Weber2018-04-047-1894/+2
| | | | | | doesn't build. llvm-svn: 329190
* [CodeGen] Generate DWARF v5 Accelerator TablesPavel Labath2018-04-047-2/+1894
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This patch adds a DwarfAccelTableEmitter class, which generates an accelerator table, as specified in DWARF v5 standard. At the moment it only generates a DIE offset column and (if we are indexing more than one compile unit) a CU column. Indexing type units is not currently supported, as we don't even have the ability to generate DWARF v5-compatible compile units. The implementation is not data-source agnostic like the one generating apple tables. This was not necessary as we currently only have one user of this code, and without a second user it was not obvious to me how to best abstract this. (The difference between these tables and the apple ones is that they need a lot more metadata about the debug info they are indexing). The generation is triggered by the --accel-tables argument, which supersedes the --dwarf-accel-tables arg -- the latter was a simple on-off switch, but not we can choose between two kinds of accelerator tables we can generate. This is tested by parsing the generated tables with llvm-dwarfdump and the DWARFVerifier, and I've also checked that GNU readelf is able to make sense of the tables. Differential Revision: https://reviews.llvm.org/D43286 llvm-svn: 329179
* [DEBUGINFO] Add option that allows to disable emission of flags in .loc ↵Alexey Bataev2018-04-031-0/+73
| | | | | | | | | | | | | | | | | | directives. Summary: Some targets do not support extended format of .loc directive and support only simple format: .loc <FileID> <Line> <Column>. Patch adds MCAsmInfo flag and option that allows emit .loc directive without additional flags. Reviewers: echristo Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D45184 llvm-svn: 329089
* Move generic test to the Generic directoryAdrian Prantl2018-03-091-0/+70
| | | | llvm-svn: 327148
* LowerDbgDeclare: ignore dbg.declares for allocas with volatile accessAdrian Prantl2018-03-091-0/+83
| | | | | | | | | | | There is no point in lowering a dbg.declare describing an alloca that has volatile loads or stores as users, since the alloca cannot be elided. Lowering the dbg.declare will result in larger debug info that may also have worse coverage than just describing the alloca. rdar://problem/34496278 llvm-svn: 327092
* [DWARF] Emit a split line table only if there are split type units.Paul Robinson2018-03-011-0/+2
| | | | | | A .debug_info.dwo section doesn't use the .debug_line.dwo section. llvm-svn: 326395
* [DebugInfo] Support DWARF v5 source code embedding extensionScott Linder2018-02-231-2/+6
| | | | | | | | | | | | | | | | | | | In DWARF v5 the Line Number Program Header is extensible, allowing values with new content types. In this extension a content type is added, DW_LNCT_LLVM_source, which contains the embedded source code of the file. Add new optional attribute for !DIFile IR metadata called source which contains source text. Use this to output the source to the DWARF line table of code objects. Analogously extend METADATA_FILE in Bitcode and .file directive in ASM to support optional source. Teach llvm-dwarfdump and llvm-objdump about the new values. Update the output format of llvm-dwarfdump to make room for the new attribute on file_names entries, and support embedded sources for the -source option in llvm-objdump. Differential Revision: https://reviews.llvm.org/D42765 llvm-svn: 325970
* [DEBUGINFO] Add support for emission of the inlined strings.Alexey Bataev2018-02-201-0/+45
| | | | | | | | | | | | | | Summary: Patch adds an option for emission of inlined strings rather than .debug_str section. Reviewers: echristo, jlebar Subscribers: eraman, llvm-commits, JDevlieghere Differential Revision: https://reviews.llvm.org/D43390 llvm-svn: 325583
* [DebugInfo] Removed assert on missing CountVarDIESander de Smalen2018-02-172-0/+48
| | | | | | | | | | | | | | | | | | | | Summary: The assert for a DISubrange's CountVarDIE to be available fails when the dbg.value() has been optimized away for any reason. Having the assert for that is a little heavy, so instead removing it now in favor of not generating the 'count' expression. Addresses http://llvm.org/PR36263 . Reviewers: aprantl, dblaikie, probinson Reviewed By: aprantl Subscribers: JDevlieghere, llvm-commits, dstenb Differential Revision: https://reviews.llvm.org/D43387 llvm-svn: 325427
* [DebugInfo] Accept enumeration types without underlying integer type present inMomchil Velikov2018-02-151-1/+16
| | | | | | | | | | debug info metadata ... when generating DWARF. Differential Revision: https://reviews.llvm.org/D43304 llvm-svn: 325234
* Re-commit r324489: [DebugInfo] Improvements to representation of enumeration ↵Momchil Velikov2018-02-121-0/+188
| | | | | | | | types (PR36168) Differential Revision: https://reviews.llvm.org/D42734 llvm-svn: 324899
* Revert "[DebugInfo] Improvements to representation of enumeration types ↵Momchil Velikov2018-02-071-188/+0
| | | | | | | | (PR36168)" Revert commit r324489, it broke LLDB tests. llvm-svn: 324511
* [DebugInfo] Improvements to representation of enumeration types (PR36168)Momchil Velikov2018-02-071-0/+188
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch is the LLVM part of fixing the issues, described in https://bugs.llvm.org/show_bug.cgi?id=36168 * The representation of enumerator values in the debug info metadata now contains a boolean flag isUnsigned, which determines how the bits of the value are interpreted. * The DW_TAG_enumeration type DIE now always (for DWARF version >= 3) includes a DW_AT_type attribute, which refers to the underlying integer type, as suggested in DWARFv4 (5.7 Enumeration Type Entries). * The debug info metadata for enumeration type contains (in flags) indication whether this is a C++11 "fixed enum". * For C++11 enumeration with a fixed underlying type, the DIE also includes the DW_AT_enum_class attribute (for DWARF version >= 4). * Encoding of enumerator constants uses DW_FORM_sdata for signed values and DW_FORM_udata for unsigned values, as suggested by DWARFv4 (7.5.4 Attribute Encodings). The changes should be backwards compatible: * the isUnsigned attribute is optional and defaults to false. * if the underlying type for the enumeration is not available, the enumerator values are considered signed. * the FixedEnum flag defaults to clear. * the bitcode format for DIEnumerator stores the unsigned flag bit #1 of the first record element, so the format does not change and the zero previously stored there is consistent with the false default for IsUnsigned. Differential Revision: https://reviews.llvm.org/D42734 llvm-svn: 324489
* Add DWARF for discriminated unionsAdrian Prantl2018-02-062-0/+145
| | | | | | | | | | | | | | | | | | | | | | | | | n Rust, an enum that carries data in the variants is, essentially, a discriminated union. Furthermore, the Rust compiler will perform space optimizations on such enums in some situations. Previously, DWARF for these constructs was emitted using a hack (a magic field name); but this approach stopped working when more space optimizations were added in https://github.com/rust-lang/rust/pull/45225. This patch changes LLVM to allow discriminated unions to be represented in DWARF. It adds createDiscriminatedUnionType and createDiscriminatedMemberType to DIBuilder and then arranges for this to be emitted using DWARF's DW_TAG_variant_part and DW_TAG_variant. Note that DWARF requires that a discriminated union be represented as a structure with a variant part. However, as Rust only needs to emit pure discriminated unions, this is what I chose to expose on DIBuilder. Patch by Tom Tromey! Differential Revision: https://reviews.llvm.org/D42082 llvm-svn: 324426
* [DWARF] Regularize dumping strings from line tables.Paul Robinson2018-02-051-2/+2
| | | | | | | | | | | | | | | | | The major visible difference here is that in line-table dumps, directory and file names are wrapped in double-quotes; previously, directory names got single quotes and file names were not quoted at all. The improvement in this patch is that when a DWARF v5 line table header has indirect strings, in a verbose dump these will all have their section[offset] printed as well as the name itself. This matches the format used for dumping strings in the .debug_info section. Differential Revision: https://reviews.llvm.org/D42802 llvm-svn: 324270
* Refactor dwarfdump -apple-names outputPavel Labath2018-01-292-23/+23
| | | | | | | | | | | | | | | | | | Summary: This modifies the dwarfdump output to align it with the new .debug_names dump. It also renames two header fields to match similar fields in the dwarf5 header. A couple of tests needed to be updated to match new output. The changes were fairly straight-forward, although not really automatable. Reviewers: JDevlieghere, aprantl Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D42415 llvm-svn: 323641
* [DWARF] Temporarily removing test to make buildbots happy while investigating.Wolfgang Pieb2018-01-261-122/+0
| | | | llvm-svn: 323564
* [DWARF] Temporarily removing a test that caused an independent failure on ↵Wolfgang Pieb2018-01-261-159/+0
| | | | | | | | the mingw target. Will recommit once that is addressed. llvm-svn: 323560
* [DWARF] Generate DWARF v5 string offsets tables along with strx* index forms.Wolfgang Pieb2018-01-263-0/+574
| | | | | | | | | | | | Summary: This is the producer side for DWARF v5 string offsets tables. The reader/consumer side was committed with r321295. All compile and type units in a module share a contribution to the string offsets table. Indirect strings use the strx{1,2,3,4} index forms. Reviewers: dblaikie, aprantl, JDevliegehere Differential Revision: https://reviews.llvm.org/D42021 llvm-svn: 323546
* [GlobalOpt] Emit fragments using field offsets from struct layoutMikael Holmen2018-01-251-1/+1
| | | | | | | | | | | | | | | | | | | | | | Summary: When creating the debug fragments for a SRA'd struct, use the fields' offsets, taken from the struct layout, as the offsets for the resulting fragments. This fixes an issue where GlobalOpt would emit fragments with incorrect offsets for padded fields. This should solve PR36016. Patch by David Stenberg. Reviewers: aprantl Reviewed By: aprantl Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D42489 llvm-svn: 323411
* [DebugInfo] Emit DWARF reference for DIVariable 'count' in DISubrangeSander de Smalen2018-01-241-0/+50
| | | | | | | | | | | | | | | | | | | | | | Summary: This patch implements the codegen of DWARF debug info for non-constant 'count' fields for DISubrange. This is patch [2/3] in a series to extend LLVM's DISubrange Metadata node to support debugging of C99 variable length arrays and vectors with runtime length like the Scalable Vector Extension for AArch64. It is also a first step towards representing more complex cases like arrays in Fortran. Reviewers: echristo, pcc, aprantl, dexonsmith, clayborg, kristof.beyls, dblaikie Reviewed By: aprantl Subscribers: fhahn, aemerson, rengolin, JDevlieghere, llvm-commits Differential Revision: https://reviews.llvm.org/D41696 llvm-svn: 323323
* Remove alignment argument from memcpy/memmove/memset in favour of alignment ↵Daniel Neilson2018-01-191-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | attributes (Step 1) Summary: This is a resurrection of work first proposed and discussed in Aug 2015: http://lists.llvm.org/pipermail/llvm-dev/2015-August/089384.html and initially landed (but then backed out) in Nov 2015: http://lists.llvm.org/pipermail/llvm-commits/Week-of-Mon-20151109/312083.html The @llvm.memcpy/memmove/memset intrinsics currently have an explicit argument which is required to be a constant integer. It represents the alignment of the dest (and source), and so must be the minimum of the actual alignment of the two. This change is the first in a series that allows source and dest to each have their own alignments by using the alignment attribute on their arguments. In this change we: 1) Remove the alignment argument. 2) Add alignment attributes to the source & dest arguments. We, temporarily, require that the alignments for source & dest be equal. For example, code which used to read: call void @llvm.memcpy.p0i8.p0i8.i32(i8* %dest, i8* %src, i32 100, i32 4, i1 false) will now read call void @llvm.memcpy.p0i8.p0i8.i32(i8* align 4 %dest, i8* align 4 %src, i32 100, i1 false) Downstream users may have to update their lit tests that check for @llvm.memcpy/memmove/memset call/declaration patterns. The following extended sed script may help with updating the majority of your tests, but it does not catch all possible patterns so some manual checking and updating will be required. s~declare void @llvm\.mem(set|cpy|move)\.p([^(]*)\((.*), i32, i1\)~declare void @llvm.mem\1.p\2(\3, i1)~g s~call void @llvm\.memset\.p([^(]*)i8\(i8([^*]*)\* (.*), i8 (.*), i8 (.*), i32 [01], i1 ([^)]*)\)~call void @llvm.memset.p\1i8(i8\2* \3, i8 \4, i8 \5, i1 \6)~g s~call void @llvm\.memset\.p([^(]*)i16\(i8([^*]*)\* (.*), i8 (.*), i16 (.*), i32 [01], i1 ([^)]*)\)~call void @llvm.memset.p\1i16(i8\2* \3, i8 \4, i16 \5, i1 \6)~g s~call void @llvm\.memset\.p([^(]*)i32\(i8([^*]*)\* (.*), i8 (.*), i32 (.*), i32 [01], i1 ([^)]*)\)~call void @llvm.memset.p\1i32(i8\2* \3, i8 \4, i32 \5, i1 \6)~g s~call void @llvm\.memset\.p([^(]*)i64\(i8([^*]*)\* (.*), i8 (.*), i64 (.*), i32 [01], i1 ([^)]*)\)~call void @llvm.memset.p\1i64(i8\2* \3, i8 \4, i64 \5, i1 \6)~g s~call void @llvm\.memset\.p([^(]*)i128\(i8([^*]*)\* (.*), i8 (.*), i128 (.*), i32 [01], i1 ([^)]*)\)~call void @llvm.memset.p\1i128(i8\2* \3, i8 \4, i128 \5, i1 \6)~g s~call void @llvm\.memset\.p([^(]*)i8\(i8([^*]*)\* (.*), i8 (.*), i8 (.*), i32 ([0-9]*), i1 ([^)]*)\)~call void @llvm.memset.p\1i8(i8\2* align \6 \3, i8 \4, i8 \5, i1 \7)~g s~call void @llvm\.memset\.p([^(]*)i16\(i8([^*]*)\* (.*), i8 (.*), i16 (.*), i32 ([0-9]*), i1 ([^)]*)\)~call void @llvm.memset.p\1i16(i8\2* align \6 \3, i8 \4, i16 \5, i1 \7)~g s~call void @llvm\.memset\.p([^(]*)i32\(i8([^*]*)\* (.*), i8 (.*), i32 (.*), i32 ([0-9]*), i1 ([^)]*)\)~call void @llvm.memset.p\1i32(i8\2* align \6 \3, i8 \4, i32 \5, i1 \7)~g s~call void @llvm\.memset\.p([^(]*)i64\(i8([^*]*)\* (.*), i8 (.*), i64 (.*), i32 ([0-9]*), i1 ([^)]*)\)~call void @llvm.memset.p\1i64(i8\2* align \6 \3, i8 \4, i64 \5, i1 \7)~g s~call void @llvm\.memset\.p([^(]*)i128\(i8([^*]*)\* (.*), i8 (.*), i128 (.*), i32 ([0-9]*), i1 ([^)]*)\)~call void @llvm.memset.p\1i128(i8\2* align \6 \3, i8 \4, i128 \5, i1 \7)~g s~call void @llvm\.mem(cpy|move)\.p([^(]*)i8\(i8([^*]*)\* (.*), i8([^*]*)\* (.*), i8 (.*), i32 [01], i1 ([^)]*)\)~call void @llvm.mem\1.p\2i8(i8\3* \4, i8\5* \6, i8 \7, i1 \8)~g s~call void @llvm\.mem(cpy|move)\.p([^(]*)i16\(i8([^*]*)\* (.*), i8([^*]*)\* (.*), i16 (.*), i32 [01], i1 ([^)]*)\)~call void @llvm.mem\1.p\2i16(i8\3* \4, i8\5* \6, i16 \7, i1 \8)~g s~call void @llvm\.mem(cpy|move)\.p([^(]*)i32\(i8([^*]*)\* (.*), i8([^*]*)\* (.*), i32 (.*), i32 [01], i1 ([^)]*)\)~call void @llvm.mem\1.p\2i32(i8\3* \4, i8\5* \6, i32 \7, i1 \8)~g s~call void @llvm\.mem(cpy|move)\.p([^(]*)i64\(i8([^*]*)\* (.*), i8([^*]*)\* (.*), i64 (.*), i32 [01], i1 ([^)]*)\)~call void @llvm.mem\1.p\2i64(i8\3* \4, i8\5* \6, i64 \7, i1 \8)~g s~call void @llvm\.mem(cpy|move)\.p([^(]*)i128\(i8([^*]*)\* (.*), i8([^*]*)\* (.*), i128 (.*), i32 [01], i1 ([^)]*)\)~call void @llvm.mem\1.p\2i128(i8\3* \4, i8\5* \6, i128 \7, i1 \8)~g s~call void @llvm\.mem(cpy|move)\.p([^(]*)i8\(i8([^*]*)\* (.*), i8([^*]*)\* (.*), i8 (.*), i32 ([0-9]*), i1 ([^)]*)\)~call void @llvm.mem\1.p\2i8(i8\3* align \8 \4, i8\5* align \8 \6, i8 \7, i1 \9)~g s~call void @llvm\.mem(cpy|move)\.p([^(]*)i16\(i8([^*]*)\* (.*), i8([^*]*)\* (.*), i16 (.*), i32 ([0-9]*), i1 ([^)]*)\)~call void @llvm.mem\1.p\2i16(i8\3* align \8 \4, i8\5* align \8 \6, i16 \7, i1 \9)~g s~call void @llvm\.mem(cpy|move)\.p([^(]*)i32\(i8([^*]*)\* (.*), i8([^*]*)\* (.*), i32 (.*), i32 ([0-9]*), i1 ([^)]*)\)~call void @llvm.mem\1.p\2i32(i8\3* align \8 \4, i8\5* align \8 \6, i32 \7, i1 \9)~g s~call void @llvm\.mem(cpy|move)\.p([^(]*)i64\(i8([^*]*)\* (.*), i8([^*]*)\* (.*), i64 (.*), i32 ([0-9]*), i1 ([^)]*)\)~call void @llvm.mem\1.p\2i64(i8\3* align \8 \4, i8\5* align \8 \6, i64 \7, i1 \9)~g s~call void @llvm\.mem(cpy|move)\.p([^(]*)i128\(i8([^*]*)\* (.*), i8([^*]*)\* (.*), i128 (.*), i32 ([0-9]*), i1 ([^)]*)\)~call void @llvm.mem\1.p\2i128(i8\3* align \8 \4, i8\5* align \8 \6, i128 \7, i1 \9)~g The remaining changes in the series will: Step 2) Expand the IRBuilder API to allow creation of memcpy/memmove with differing source and dest alignments. Step 3) Update Clang to use the new IRBuilder API. Step 4) Update Polly to use the new IRBuilder API. Step 5) Update LLVM passes that create memcpy/memmove calls to use the new IRBuilder API, and those that use use MemIntrinsicInst::[get|set]Alignment() to use getDestAlignment() and getSourceAlignment() instead. Step 6) Remove the single-alignment IRBuilder API for memcpy/memmove, and the MemIntrinsicInst::[get|set]Alignment() methods. Reviewers: pete, hfinkel, lhames, reames, bollu Reviewed By: reames Subscribers: niosHD, reames, jholewinski, qcolombet, jfb, sanjoy, arsenm, dschuff, dylanmckay, mehdi_amini, sdardis, nemanjai, david2050, nhaehnle, javed.absar, sbc100, jgravelle-google, eraman, aheejin, kbarton, JDevlieghere, asb, rbar, johnrusso, simoncook, jordy.potman.lists, apazos, sabuasal, llvm-commits Differential Revision: https://reviews.llvm.org/D41675 llvm-svn: 322965
* add 'REQUIRES: object-emission' to testAdrian Prantl2018-01-051-0/+1
| | | | llvm-svn: 321875
* remove unnecessary target triple from generic testAdrian Prantl2018-01-051-4/+0
| | | | llvm-svn: 321874
* Debug Info: Support DW_AT_calling_convention on composite types.Adrian Prantl2018-01-051-0/+63
| | | | | | | | | | | | | | | | | | | | | | | | | | | | This implements the DWARF 5 feature described at http://www.dwarfstd.org/ShowIssue.php?issue=141215.1 This allows a consumer to understand whether a composite data type is trivially copyable and thus should be passed by value instead of by reference. The canonical example is being able to distinguish the following two types: // S is not trivially copyable because of the explicit destructor. struct S { ~S() {} }; // T is a POD type. struct T { ~T() = default; }; This patch adds two new (DI)flags to LLVM metadata: TypePassByValue and TypePassByReference. <rdar://problem/36034922> Differential Revision: https://reviews.llvm.org/D41743 llvm-svn: 321844
* [SimplifyCFG] don't sink common insts too soon (PR34603)Sanjay Patel2017-12-141-1/+1
| | | | | | | | | | | | This should solve: https://bugs.llvm.org/show_bug.cgi?id=34603 ...by preventing SimplifyCFG from altering redundant instructions before early-cse has a chance to run. It changes the default (canonical-forming) behavior of SimplifyCFG, so we're only doing the sinking transform later in the optimization pipeline. Differential Revision: https://reviews.llvm.org/D38566 llvm-svn: 320749
OpenPOWER on IntegriCloud