[PATCH] D141072: [NVPTX] Work around syntax error in PTX assembly

[Luke Drummond via Phabricator via llvm-commits]

ldrumm created this revision.
ldrumm added reviewers: tra, eliben, echristo, jholewinski, arsenm.
Herald added subscribers: kosarev, mattd, gchakrabarti, asavonic, hiraditya, kristof.beyls, tpr.
Herald added a project: All.
ldrumm requested review of this revision.
Herald added a subscriber: wdng.
Herald added a project: LLVM.

The PTX assembler doesn't like dots in symbol names. We have a pass that
fixes this (NVPTXAssignValidGlobalNames - since 264cd4672d), but there's
a pernicious bug in the way debug info is emitted that means this pass
alone won't work properly if it's ever run as part of the codegen
pipeline involving debug info emission.

`AsmPrinter::doInitialization` collects all metadata and initializes all
the DWARF DIEs that are later emitted after the main module has been
printed. Naturally, `doInitialization` is executed *before* any of the
other passes contained in the same PassManager execute their
`runOnModule` functions that may arbitrarily modify the module.
If any of those functions try and modify the module in such a way that
the debuginfo goes out of date, then the debuginfo *will* be out of date
once the AsmPrinter actually gets to finalize printing the debug info.

As far as I can tell: any code that runs in the same PassManager as the
AsmPrinter could result in bad debug info.

I don't see a simple way around this, unless DWARF debug info is
collected and printed a different way - probably during the
`runOnModule` method. That will be much more disruptive change, so for
now the small (!) hack introduced here sanitizes the symbol names
referred to by the `MCSymbolRefExpr` that is earlier constructed by the
AsmPrinter's DWARF handler.

N.B. There's the slight possibility that this also introduces a new bug

- sanitized symbol names referred to by the MCExprs may not be of

private linkage, and so may not actually exist. Given that symbols with
dots in them are are already illegal according to ptxas, I don't think
this is a practical issue to worry about.

Since the NVPTXUtilities are now used by the MC layer, I've hoisted them
into their own `Utils` lib as per ARM and AMDGPU.

Fixes https://github.com/intel/llvm/issues/5980


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D141072

Files:
  llvm/lib/Target/NVPTX/CMakeLists.txt
  llvm/lib/Target/NVPTX/MCTargetDesc/CMakeLists.txt
  llvm/lib/Target/NVPTX/MCTargetDesc/NVPTXTargetStreamer.cpp
  llvm/lib/Target/NVPTX/MCTargetDesc/NVPTXTargetStreamer.h
  llvm/lib/Target/NVPTX/NVPTXAsmPrinter.cpp
  llvm/lib/Target/NVPTX/NVPTXAssignValidGlobalNames.cpp
  llvm/lib/Target/NVPTX/NVPTXGenericToNVVM.cpp
  llvm/lib/Target/NVPTX/NVPTXISelDAGToDAG.cpp
  llvm/lib/Target/NVPTX/NVPTXISelLowering.cpp
  llvm/lib/Target/NVPTX/NVPTXImageOptimizer.cpp
  llvm/lib/Target/NVPTX/NVPTXLowerAlloca.cpp
  llvm/lib/Target/NVPTX/NVPTXLowerArgs.cpp
  llvm/lib/Target/NVPTX/NVPTXTargetTransformInfo.cpp
  llvm/lib/Target/NVPTX/NVPTXUtilities.cpp
  llvm/lib/Target/NVPTX/NVPTXUtilities.h
  llvm/lib/Target/NVPTX/Utils/CMakeLists.txt
  llvm/lib/Target/NVPTX/Utils/NVPTXUtilities.cpp
  llvm/lib/Target/NVPTX/Utils/NVPTXUtilities.h

-------------- next part --------------
A non-text attachment was scrubbed...
Name: D141072.486614.patch
Type: text/x-patch
Size: 9612 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20230105/9517af82/attachment.bin>