Changes in debug-addr-class.ll

2e7e0975 - [NVPTX] Prefix "$L__" for branch label names

Sat, 30 Apr 2022 19:55:20 +0000

[NVPTX] Prefix "$L__" for branch label namesA global variable may have the same name as a label, and ptxas does not accept it.Prefix labels with $L__ to fix this.Reviewed By: MaskRay, traDifferential Revision: https://reviews.llvm.org/D119669 List of files: /llvm-project-15.0.7/llvm/test/DebugInfo/NVPTX/debug-addr-class.ll

0f1b5f11 - [NVPTX] Integrate ptxas to LIT tests

Wed, 27 Apr 2022 19:43:55 +0000

[NVPTX] Integrate ptxas to LIT testsptxas is a proprietary compiler from Nvidia that can compile PTX tomachine code (SASS). It has a lot of diagnostics to catch errorsin PTX, which can be used to verify PTX output from llc.Set -DPXTAS_EXECUTABLE=/path/to/ptxas CMake option to enable it.If this option is not set, then ptxas is substituted to true whicheffectively disables all ptxas RUN lines.LLVM_PTXAS_EXECUTABLE environment variable takes precedence overthe CMake option, and allows to override ptxas executable that is used for LITwithout complete re-configuration.Differential Revision: https://reviews.llvm.org/D121727 List of files: /llvm-project-15.0.7/llvm/test/DebugInfo/NVPTX/debug-addr-class.ll

a00ae86a - Revert D119669 "[NVPTX] Prefix "$L__" for branch label names"

Mon, 14 Feb 2022 21:23:22 +0000

Revert D119669 "[NVPTX] Prefix "$L__" for branch label names"This reverts commit cccef321096c20825fe8738045c1d91d3b9fd57d.Broke clang-cuda-t4```/buildbot/cuda-t4-0/work/clang-cuda-t4/clang/bin/clang++ -DNDEBUG -O3 -DNDEBUG -w -Werror=date-time -UNDEBUG --cuda-path=/buildbot/cuda-t4-0/work/clang-cuda-t4/external/cuda/cuda-11.0 -I/buildbot/cuda-t4-0/work/clang-cuda-t4/external/cuda/cuda-11.0/include --cuda-gpu-arch=sm_75 -std=c++20 -stdlib=libstdc++ --gcc-toolchain=/buildbot/cuda-t4-0/work/clang-cuda-t4/external/cuda/gcc-8 -DSTDLIB_VERSION=2014 -MD -MT External/CUDA/CMakeFiles/complex-cuda-11.0-c++20-libstdc++-8.dir/complex.cu.o -MF External/CUDA/CMakeFiles/complex-cuda-11.0-c++20-libstdc++-8.dir/complex.cu.o.d -o External/CUDA/CMakeFiles/complex-cuda-11.0-c++20-libstdc++-8.dir/complex.cu.o -c /buildbot/cuda-t4-0/work/clang-cuda-t4/llvm-test-suite/External/CUDA/complex.cuptxas /tmp/complex-cfa050/complex-sm_75.s, line 250; fatal : Parsing error near '$L__BB6_2': syntax errorptxas fatal : Ptx assembly aborted due to errors``` List of files: /llvm-project-15.0.7/llvm/test/DebugInfo/NVPTX/debug-addr-class.ll

cccef321 - [NVPTX] Prefix "$L__" for branch label names

Mon, 14 Feb 2022 20:51:36 +0000

81378f7e - Revert "[DwarfDebug] Support emitting function-local declaration for a lexical block" & dependent patches

Thu, 23 Dec 2021 16:10:52 +0000

Revert "[DwarfDebug] Support emitting function-local declaration for a lexical block" & dependent patchesTry to revert D113741 once again.This also reverts 0ac75e82fff93a80ca401d3db3541e8d1d9098f9 (D114705)as it causes LLDB's lldb-api.lang/cpp/nsimport.TestCppNsImport.py testfailure w/o D113741.This reverts commit f9607d45f399e2afc39ec16222ea68b4e0831564.Differential Revision: https://reviews.llvm.org/D116225 List of files: /llvm-project-15.0.7/llvm/test/DebugInfo/NVPTX/debug-addr-class.ll

0ac75e82 - Reland [DwarfDebug] Move emission of global vars, types and imports to endModule()

Sat, 04 Dec 2021 12:08:10 +0000

Reland [DwarfDebug] Move emission of global vars, types and imports to endModule()This patch proposes to move emission of global variables, types,imported entities, etc from DwarfDebug::beginModule() to DwarfDebug::endModule().Effectively, this changes nothing but the order of debug entities whichwill be as follows:* subprograms (including related context, local variables/labels, local imported entities; related types can be created as a part of the emission of local entities of an abstract subprogram);* global variables (including related context and types);* retained types and enums;* non-local-scoped imported entities;* basic types;* other types left (as a part of local variables attributes emission).Note that the order of emitted compile units may also be changed as now we emitunits that contain subprograms first and then all other non-empty units.The motivation behind this change is the following:(1) DwarfDebug::beginModule() is run at the very beginning of backend's pipeline, from this time IR can be significantly changed by target-specific passes. If it happens for debug metadata of global entities, those changes will not be reflected in the emitted DWARF.(2) imported subprogram names should refer to an abstract subprogram if it exists, but it isn't known in DwarfDebug::beginModule() (it's possible to make some guesses based on location info, but it's not quite reliable);(3) aforementioned entities if they are scoped within a bracketed block (subject of D113741) couldn't be emitted in DwarfDebug::beginModule() (they need parent emitted first). Another problem is if to try to gather some information about local entities and defer their emission (till subprogram's processing or DwarfDebug::endModule()) all the gathered details might be irrelevant / invalid by the time the entities are being emitted (because of (1)).Reviewed By: dblaikieDifferential Revision: https://reviews.llvm.org/D114705 List of files: /llvm-project-15.0.7/llvm/test/DebugInfo/NVPTX/debug-addr-class.ll

a9616048 - Revert "[DwarfDebug] Support emitting function-local declaration for a lexical block"

Sat, 04 Dec 2021 16:03:46 +0000

Revert "[DwarfDebug] Support emitting function-local declaration for a lexical block"This reverts commits* ee691970a9a85470948ada623c31f0ab8773617c (D113741),* 79d3132998b2828be8f7d2ec411f91fb11b3e01f (D114705)due to lldb and dexter test failures. List of files: /llvm-project-15.0.7/llvm/test/DebugInfo/NVPTX/debug-addr-class.ll

79d31329 - [DwarfDebug] Move emission of global vars, types and imports to endModule()

Sat, 04 Dec 2021 12:08:10 +0000

[DwarfDebug] Move emission of global vars, types and imports to endModule()This patch proposes to move emission of global variables, types,imported entities, etc from DwarfDebug::beginModule() to DwarfDebug::endModule().Effectively, this changes nothing but the order of debug entities whichwill be as follows:* subprograms (including related context, local variables/labels, local imported entities; related types can be created as a part of the emission of local entities of an abstract subprogram);* global variables (including related context and types);* retained types and enums;* non-local-scoped imported entities;* basic types;* other types left (as a part of local variables attributes emission).Note that the order of emitted compile units may also be changed as now we emitunits that contain subprograms first and then all other non-empty units.The motivation behind this change is the following:(1) DwarfDebug::beginModule() is run at the very beginning of backend's pipeline, from this time IR can be significantly changed by target-specific passes. If it happens for debug metadata of global entities, those changes will not be reflected in the emitted DWARF.(2) imported subprogram names should refer to an abstract subprogram if it exists, but it isn't known in DwarfDebug::beginModule() (it's possible to make some guesses based on location info, but it's not quite reliable);(3) aforementioned entities if they are scoped within a bracketed block (subject of D113741) couldn't be emitted in DwarfDebug::beginModule() (they need parent emitted first). Another problem is if to try to gather some information about local entities and defer their emission (till subprogram's processing or DwarfDebug::endModule()) all the gathered details might be irrelevant / invalid by the time the entities are being emitted (because of (1)).Reviewed By: dblaikieDifferential Revision: https://reviews.llvm.org/D114705 List of files: /llvm-project-15.0.7/llvm/test/DebugInfo/NVPTX/debug-addr-class.ll

1d68e0a0 - Reland [DWARF] Location-less inlined variables should not have DW_TAG_variable

Wed, 10 Feb 2021 15:40:47 +0000

Reland [DWARF] Location-less inlined variables should not have DW_TAG_variableOriginally landed in ddc2f1e3fb4 and reverted in d32deaab4d because ofa Generic test objecting. That was fixed up in 013613964fd9. Originallanding commit message follows:[DWARF] Location-less inlined variables should not have DW_TAG_variableDiscussed in this thread: https://lists.llvm.org/pipermail/llvm-dev/2021-January/148139.htmlDwarfDebug::collectEntityInfo accidentally distinguishes between variablelocations that never have a location specified, and variable locations thathave an empty location specified. The latter leads to the creation of anempty variable referring to the abstract origin.Fix this by seeking a non-empty location before producing a concreteentity, to guarantee a DW_AT_location will be produced. Other loops incollectEntityInfo and endFunctionImpl take care of examining theretainedNodes collection and ensuring optimised-out variables are created.Differential Revision: https://reviews.llvm.org/D95617 List of files: /llvm-project-15.0.7/llvm/test/DebugInfo/NVPTX/debug-addr-class.ll

d32deaab - Revert "[DWARF] Location-less inlined variables should not have DW_TAG_variable"

Wed, 03 Feb 2021 17:54:33 +0000

Revert "[DWARF] Location-less inlined variables should not have DW_TAG_variable"This reverts commit ddc2f1e3fb4f8f9ae7dd130e40b60cfc775eba24.A build-bot objected: http://lab.llvm.org:8011/#builders/105/builds/5486 List of files: /llvm-project-15.0.7/llvm/test/DebugInfo/NVPTX/debug-addr-class.ll

ddc2f1e3 - [DWARF] Location-less inlined variables should not have DW_TAG_variable

Wed, 03 Feb 2021 17:27:30 +0000

[DWARF] Location-less inlined variables should not have DW_TAG_variableDiscussed in this thread: https://lists.llvm.org/pipermail/llvm-dev/2021-January/148139.htmlDwarfDebug::collectEntityInfo accidentally distinguishes between variablelocations that never have a location specified, and variable locations thathave an empty location specified. The latter leads to the creation of anempty variable referring to the abstract origin.Fix this by seeking a non-empty location before producing a concreteentity, to guarantee a DW_AT_location will be produced. Other loops incollectEntityInfo and endFunctionImpl take care of examining theretainedNodes collection and ensuring optimised-out variables are created.Differential Revision: https://reviews.llvm.org/D95617 List of files: /llvm-project-15.0.7/llvm/test/DebugInfo/NVPTX/debug-addr-class.ll

77ffce69 - [Instruction] Set metadata uses to undef on deletion

Wed, 20 May 2020 01:03:22 +0000

[Instruction] Set metadata uses to undef on deletionSummary:Replace any extant metadata uses of a dying instruction with undef topreserve debug info accuracy. Some alternatives include:- Treat Instruction like any other Value, and point its extant metadata uses to an empty ValueAsMetadata node. This makes extant dbg.value uses trivially dead (i.e. fair game for deletion in many passes), leading to stale dbg.values being in effect for too long.- Call salvageDebugInfoOrMarkUndef. Not needed to make instruction removal correct. OTOH results in wasted work in some common cases (e.g. when all instructions in a BasicBlock are deleted).This came up while discussing some basic cases inhttps://reviews.llvm.org/D80052.Reviewers: jmorse, TWeaver, aprantl, dexonsmith, jdoerfertSubscribers: jholewinski, qcolombet, hiraditya, jfb, sstefan1, llvm-commitsTags: #llvmDifferential Revision: https://reviews.llvm.org/D80264 List of files: /llvm-project-15.0.7/llvm/test/DebugInfo/NVPTX/debug-addr-class.ll

736273c7 - DebugInfo: Do not create a debug_macinfo section if no CUs have associated macros

Fri, 08 Nov 2019 23:26:17 +0000

DebugInfo: Do not create a debug_macinfo section if no CUs have associated macrosPatch based on Sourabh Singh's D69839 patch. List of files: /llvm-project-15.0.7/llvm/test/DebugInfo/NVPTX/debug-addr-class.ll

3951245c - NVPTX: Don't insert an extra empty line at the end of the last section.

Fri, 08 Nov 2019 23:14:58 +0000

NVPTX: Don't insert an extra empty line at the end of the last section.This was arbitrarily appearing in only the last section emitted - whichmade tests more sensitive than they needed to be (removing the lastsection - like the macinfo section change that's coming after this)would, surprisingly, move the blank line to the previous section. List of files: /llvm-project-15.0.7/llvm/test/DebugInfo/NVPTX/debug-addr-class.ll

39c308f6 - DebugInfo: Use separate macinfo contributions for each CU

Fri, 08 Nov 2019 20:56:49 +0000

DebugInfo: Use separate macinfo contributions for each CUThe macinfo support was broken for LTO situations, by terminatingmacinfo lists only once - multiple macinfo contributions were correctlylabeled, but they all continued/flowed into later contributions untilonly one terminator appeared at the end of the section.Correctly terminate each contribution & fix the parsing to handle thissituation too. The parsing fix is also necessary for dumping linkedbinaries - the previous code would stop at the end of the firstcontribution - missing all later contributions in a linked binary.It'd be nice to improve the dumping to print the offsets of eachcontribution so it'd be easier to know which CU AT_macro_info refers towhich macinfo contribution. List of files: /llvm-project-15.0.7/llvm/test/DebugInfo/NVPTX/debug-addr-class.ll

a8b3eb46 - [NVPTX][DEBUGINFO]Temp workaround for crash of ptxas: disable packed bytes in debug sections.

Fri, 08 Mar 2019 21:29:17 +0000

[NVPTX][DEBUGINFO]Temp workaround for crash of ptxas: disable packed bytes in debug sections.Summary:This patch works around the bug in the ptxas tool with the processing of bytesseparated by the comma symbol. The emission of the packed string istemporarily disabled.Reviewers: traSubscribers: jholewinski, jdoerfert, llvm-commitsTags: #llvmDifferential Revision: https://reviews.llvm.org/D59148llvm-svn: 355740 List of files: /llvm-project-15.0.7/llvm/test/DebugInfo/NVPTX/debug-addr-class.ll

f3a91503 - [DEBUG_INFO][NVPTX] Generate DW_AT_address_class to get the values in debugger.

Tue, 05 Feb 2019 19:33:47 +0000

[DEBUG_INFO][NVPTX] Generate DW_AT_address_class to get the values in debugger.Summary:According tohttps://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 allvariable and parameter. It means, that DW_AT_address_class attributeshould be used in the non-standard way to support compatibility with thecuda-gdb debugger.Clang is able to generate the information about the variable addressclass. This information is emitted as the expression sequence`DW_OP_constu DW_OP_swap DW_OP_xderef`. The patchtries to find all such expressions and transform them into`DW_AT_address_class ` if target is NVPTX and the debugger is gdb.If the expression is not found, then default values are used. For thelocal variables is set to ADDR_local_space(6), forthe globals is set to ADDR_global_space(5). Thevalues are taken from the table in the same section 5.2. CUDA-SpecificDWARF Definitions.Reviewers: echristo, probinsonSubscribers: jholewinski, aprantl, llvm-commitsDifferential Revision: https://reviews.llvm.org/D57157llvm-svn: 353203 List of files: /llvm-project-15.0.7/llvm/test/DebugInfo/NVPTX/debug-addr-class.ll