[aarch64][win] Update Called Globals info when updating Call Site info (#122762)

Fixes the "use after poison" issue introduced by #121516 (see
<https://github.com/llvm/llvm-project/pull/121516#issue

[aarch64][win] Update Called Globals info when updating Call Site info (#122762)

Fixes the "use after poison" issue introduced by #121516 (see
<https://github.com/llvm/llvm-project/pull/121516#issuecomment-2585912395>).

The root cause of this issue is that #121516 introduced "Called Global"
information for call instructions modeling how "Call Site" info is
stored in the machine function, HOWEVER it didn't copy the
copy/move/erase operations for call site information.

The fix is to rename and update the existing copy/move/erase functions
so they also take care of Called Global info.

show more ...

[LLVM][DWARF] Create debug names entry for non-tu top level DIE (#121856)

When creating a Type Unit (TU), LLVM attempts to do so optimistically.
However, if this fails, it discards the TU state and

[LLVM][DWARF] Create debug names entry for non-tu top level DIE (#121856)

When creating a Type Unit (TU), LLVM attempts to do so optimistically.
However, if this fails, it discards the TU state and creates the TU
within the Compilation Unit (CU). In such cases, an entry for the
top-level DIE is not created in the debug names table.
This can cause issues when running llvm-dwarfdump --debug-names
--verify, as the missing entry will result in verification failure.
To address this issue, this patch adds a call to the
updateAcceleratorTables when TU creation fails. This ensures that the
debug names table is updated correctly, even in cases where TU creation
fails.

show more ...

[DebugInfo] Handle trailing empty blocks when seeking prologue_end spot (#117320)

The optimiser will produce empty blocks that are unconditionally
executed according to the CFG -- while it may not

[DebugInfo] Handle trailing empty blocks when seeking prologue_end spot (#117320)

The optimiser will produce empty blocks that are unconditionally
executed according to the CFG -- while it may not be meaningful code,
and won't get a prologue_end position, we need to not crash on this
input.

The fault comes from assuming that there's always a next block with some
instructions in it, that will eventually produce some meaningful control
flow to stop at -- in the given reproducer in issue #117206 this isn't
true, because the function terminates with `unreachable`. Thus, I've
refactored the "get next instruction logic" into a helper that'll step
through all blocks and terminate if there aren't any more.

Reproducer from aeubanks

show more ...

[DebugInfo] Don't pick prologue_end if there are no instructions

Add a filter to avoid picking prologue_end when a function is empty (it may
have blocks but no instructions). This saves us from push

[DebugInfo] Don't pick prologue_end if there are no instructions

Add a filter to avoid picking prologue_end when a function is empty (it may
have blocks but no instructions). This saves us from pushing more
validity-checking into findPrologueEndLoc.

show more ...

Reapply ccddb6ffad1, "Emit a worst-case prologue_end"

In 39b2979a4 Pavel has kindly refined the implementation of a test in such
a way that it doesn't trip up over this patch -- the test wishes to
s

Reapply ccddb6ffad1, "Emit a worst-case prologue_end"

In 39b2979a4 Pavel has kindly refined the implementation of a test in such
a way that it doesn't trip up over this patch -- the test wishes to
stimulate LLDBs presentation of line0 locations, rather than wanting to
always step on line-zero on entry to artificial_location.c. As that's what
was tripping up this change, reapply.

Original commit message follows.

[DWARF] Emit a worst-case prologue_end flag for pathological inputs (#107849)

prologue_end usually indicates where the end of the function-initialization
lies, and is where debuggers usually choose to put the initial breakpoint
for a function. Our current algorithm piggy-backs it on the first available
source-location: which doesn't necessarily have anything to do with the
start of the function.

To avoid this in heavily-optimised code that lacks many useful source
locations, pick a worst-case "if all else fails" prologue_end location, of
the first instruction that appears to do meaningful computation. It'll be
given the function-scope line number, which should run-on from the start of
the function anyway. This means if your code is completely inverted by the
optimiser, you can at least put a breakpoint at the _start_ like you
expect, even if it's difficult to then step through.

This patch also attempts to preserve some good behaviour we have without
optimisations -- at O0, if the prologue immediately falls into a loop body
without any computation happening, then prologue_end lands at the start of
that loop. This is desirable; but does mean we need to do more work to
detect and support those situations.

show more ...

[DebugInfo][DWARF] Emit Per-Function Line Table Offsets and End Sequences (#110192)

**Summary**

This patch introduces a new compiler option `-mllvm
-emit-func-debug-line-table-offsets` that enab

[DebugInfo][DWARF] Emit Per-Function Line Table Offsets and End Sequences (#110192)

**Summary**

This patch introduces a new compiler option `-mllvm
-emit-func-debug-line-table-offsets` that enables the emission of
per-function line table offsets and end sequences in DWARF debug
information. This enhancement allows tools and debuggers to accurately
attribute line number information to their corresponding functions, even
in scenarios where functions are merged or share the same address space
due to optimizations like Identical Code Folding (ICF) in the linker.

**Background**
RFC: [New DWARF Attribute for Symbolication of Merged
Functions](https://discourse.llvm.org/t/rfc-new-dwarf-attribute-for-symbolication-of-merged-functions/79434)

Previous similar PR:
[#93137](https://github.com/llvm/llvm-project/pull/93137) – This PR was
very similar to the current one but at the time, the assembler had no
support for emitting labels within the line table. That support was
added in PR [#99710](https://github.com/llvm/llvm-project/pull/99710) -
and in this PR we use some of the support added in the assembler PR.

In the current implementation, Clang generates line information in the
`debug_line` section without directly associating line entries with
their originating `DW_TAG_subprogram` DIEs. This can lead to issues when
post-compilation optimizations merge functions, resulting in overlapping
address ranges and ambiguous line information.

For example, when functions are merged by ICF in LLD, multiple functions
may end up sharing the same address range. Without explicit linkage
between functions and their line entries, tools cannot accurately
attribute line information to the correct function, adversely affecting
debugging and call stack resolution.


**Implementation Details**
To address the above issue, the patch makes the following key changes:

**`DW_AT_LLVM_stmt_sequence` Attribute**: Introduces a new LLVM-specific
attribute `DW_AT_LLVM_stmt_sequence` to each `DW_TAG_subprogram` DIE.
This attribute holds a label pointing to the offset in the line table
where the function's line entries begin.

**End-of-Sequence Markers**: Emits an explicit DW_LNE_end_sequence after
each function's line entries in the line table. This marks the end of
the line information for that function, ensuring that line entries are
correctly delimited.

**Assembler and Streamer Modifications**: Modifies the MCStreamer and
related classes to support emitting the necessary labels and tracking
the current function's line entries. A new flag
GenerateFuncLineTableOffsets is added to control this behavior.

**Compiler Option**: Introduces the `-mllvm
-emit-func-debug-line-table-offsets` option to enable this
functionality, allowing users to opt-in as needed.

show more ...

Revert "[DWARF] Emit a worst-case prologue_end flag for pathological inputs (#107849)"

This reverts commit bf483ddb42065405e345393e022dc72357ec5a3a.

See PR, there's a test testing for this behaviou

Revert "[DWARF] Emit a worst-case prologue_end flag for pathological inputs (#107849)"

This reverts commit bf483ddb42065405e345393e022dc72357ec5a3a.

See PR, there's a test testing for this behaviour (possibly adaptable), and
a duplicate line entry too

show more ...

[DebugInfo] Don't apply is_stmt on MBB branches that preserve lines (#108251)

This patch follows on from the changes made in #105524, by adding an
additional heuristic that prevents us from applyin

[DebugInfo] Don't apply is_stmt on MBB branches that preserve lines (#108251)

This patch follows on from the changes made in #105524, by adding an
additional heuristic that prevents us from applying the start-of-MBB
is_stmt flag when we can see that, for all direct branches to the MBB,
the last line stepped on before the branch is the same as the first line
of the MBB. This is mainly to prevent certain pathological cases, such
as macros that expand to multiple basic blocks that all have the same
source location, from giving us repeated steps on the same line. This
approach is not comprehensive, since it relies on analyzeBranch to read
edges, but the default fallback of applying is_stmt may lead only to
useless steps in some cases, rather than skipping useful steps
altogether.

show more ...

[DWARF] Emit a worst-case prologue_end flag for pathological inputs (#107849)

prologue_end usually indicates where the end of the function-initialization
lies, and is where debuggers usually choose

[DWARF] Emit a worst-case prologue_end flag for pathological inputs (#107849)

prologue_end usually indicates where the end of the function-initialization
lies, and is where debuggers usually choose to put the initial breakpoint
for a function. Our current algorithm piggy-backs it on the first available
source-location: which doesn't necessarily have anything to do with the
start of the function.

To avoid this in heavily-optimised code that lacks many useful source
locations, pick a worst-case "if all else fails" prologue_end location, of
the first instruction that appears to do meaningful computation. It'll be
given the function-scope line number, which should run-on from the start of
the function anyway. This means if your code is completely inverted by the
optimiser, you can at least put a breakpoint at the _start_ like you
expect, even if it's difficult to then step through.

This patch also attempts to preserve some good behaviour we have without
optimisations -- at O0, if the prologue immediately falls into a loop body
without any computation happening, then prologue_end lands at the start of
that loop. This is desirable; but does mean we need to do more work to
detect and support those situations.

show more ...

[AsmPrinter] Remove unused includes (NFC) (#114698)

Identified with misc-include-cleaner.

Fix performance bug in buildLocationList (#109343)

In buildLocationList, with basic block sections, we iterate over
every basic block twice to detect section start and end. This is
sub-optimal and

Fix performance bug in buildLocationList (#109343)

In buildLocationList, with basic block sections, we iterate over
every basic block twice to detect section start and end. This is
sub-optimal and shows up as significantly time consuming when
compiling large functions.

This patch uses the set of sections already stored in MBBSectionRanges
and iterates over sections rather than basic blocks.

When detecting if loclists can be merged, the end label of an entry is
matched with the beginning label of the next entry. For the section
corresponding to the entry basic block, this is skipped. This is
because the loc list uses the end label corresponding to the function
whereas the MBBSectionRanges map uses the function end label.

For example:

.Lfunc_begin0:
.file
.loc 0 4 0 # ex2.cc:4:0
.cfi_startproc
.Ltmp0:
.loc 0 8 5 prologue_end # ex2.cc:8:5
....
.LBB_END0_0:
.cfi_endproc
.section .text._Z4testv,"ax",@progbits,unique,1
...
.Lfunc_end0:
.size _Z4testv, .Lfunc_end0-_Z4testv

The debug loc uses ".LBB_END0_0" for the end of the section whereas
MBBSectionRanges uses ".Lfunc_end0".

It is alright to skip this as we already check the section corresponding
to the debugloc entry.

Added a new test case to check that if this works correctly when the
variable's value is mutated in the entry section.

show more ...

[CodeGen] Simplify code with *Map::operator[] (NFC) (#112075)

[NVPTX] add support for .debug_loc section (#110905)

Enable .debug_loc section for NVPTX backend.

This commit makes NVPTX omit DW_AT_low_pc (and DW_AT_high_pc) for
DW_TAG_compile_unit. This is b

[NVPTX] add support for .debug_loc section (#110905)

Enable .debug_loc section for NVPTX backend.

This commit makes NVPTX omit DW_AT_low_pc (and DW_AT_high_pc) for
DW_TAG_compile_unit. This is because cuda-gdb uses the compile unit's
low_pc as a base address, and adds the addresses in the debug_loc
section to it. Removing low_pc is equivalent to setting that base
address to zero, so addition doesn't break the location ranges.
Additionally, this patch forces debug_loc label emission to emit single
labels with no subtraction or base. This would not be necessary if we
could emit `label1 - label2` expressions in PTX. The PTX documentation
at
https://docs.nvidia.com/cuda/parallel-thread-execution/index.html#debugging-directives-section
makes it seem like this is supported, but it doesn't actually work. I
believe when that documentation says that you can subtract “label
addresses between labels in the same dwarf section”, it doesn't merely
mean that the labels need to be in the same section as each other, but
in fact they need to be in the same section as the use. If support for
label subtraction is supported such that in the debug_loc section you
can subtract labels from the main code section, then we can remove the
workarounds added in this PR.

Also, since this now emits valid .debug_loc sections, it replaces the
empty .debug_loc to force existence of at least one debug section with
an empty .debug_macinfo section, which matches what nvcc does.

show more ...

[NFC] Use initial-stack-allocations for more data structures (#110544)

This replaces some of the most frequent offenders of using a DenseMap that
cause a malloc, where the typical element-count is

[NFC] Use initial-stack-allocations for more data structures (#110544)

This replaces some of the most frequent offenders of using a DenseMap that
cause a malloc, where the typical element-count is small enough to fit in
an initial stack allocation.

Most of these are fairly obvious, one to highlight is the collectOffset
method of GEP instructions: if there's a GEP, of course it's going to have
at least one offset, but every time we've called collectOffset we end up
calling malloc as well for the DenseMap in the MapVector.

show more ...

[llvm] use 64-bit types for result of getDwarfRegNum (NFC) (#109494)

The register encoding used by NVPTX and cuda-gdb basically use strings
encoded as numbers. They are always within 64-bits, but t

[llvm] use 64-bit types for result of getDwarfRegNum (NFC) (#109494)

The register encoding used by NVPTX and cuda-gdb basically use strings
encoded as numbers. They are always within 64-bits, but typically
outside of 32-bits, since they often need at least 5 characters.

This patch changes the signature of `MCRegisterInfo::getDwarfRegNum` and
some related data structures to use 64-bit numbers to accommodate
encodings like this.

Additionally, `MCRegisterInfo::getDwarfRegNum` is marked as virtual, so
that targets with peculiar dwarf register mapping schemes (such as
NVPTX) can override its behavior.

I originally tried to do a broader switch to 64-bit types for registers,
but it caused many problems. There are various places in code generation
where registers are not just treated as 32-bit numbers, but also treat
certain bit offsets as flags. So I limited the change as much as
possible to just the output of `getDwarfRegNum`. Keeping the types used
by `DwarfLLVMRegPair` as unsigned preserves the current behaviors. The
only way to give a 64-bit output from `getDwarfRegNum` that actually
needs more than 32-bits is to override `getDwarfRegNum` and provide an
implementation that sidesteps the use of the `DwarfLLVMRegPair` maps
defined in tablegen files.

First layer of stack supporting:
https://github.com/llvm/llvm-project/pull/109495

show more ...

[DebugInfo] Don't emit .loc directive with all values zero (#109978)

When emitting debug info for code alignment, it was possible to emit a
.loc directive with a file number of zero, which is inval

[DebugInfo] Don't emit .loc directive with all values zero (#109978)

When emitting debug info for code alignment, it was possible to emit a
.loc directive with a file number of zero, which is invalid for DWARF 4
and earlier. This happened because getCurrentDwarfLoc() returned a
zero-initialised value when there hadn't been a previous .loc directive
emitted.

---------

Co-authored-by: Paul T Robinson <paul.robinson@sony.com>

show more ...

Revert2 "[DebugInfo][DWARF] Set is_stmt on first non-line-0 instruction in BB (#105524)"

Reverted due to large .debug_line size regressions for some
configurations; work currently in place to improv

Revert2 "[DebugInfo][DWARF] Set is_stmt on first non-line-0 instruction in BB (#105524)"

Reverted due to large .debug_line size regressions for some
configurations; work currently in place to improve the output of this
behaviour in PR #108251.

This patch also modifies two tests that were created or modified after
the original commit landed and are affected by the revert:

llvm/test/CodeGen/X86/pseudo_cmov_lower2.ll
llvm/test/DebugInfo/X86/empty-line-info.ll

This reverts commit 5fef40c2c477e92187bd4e5c18091eca6b8465cc.

show more ...

[DWARF] Emit a minimal line-table for totally empty functions (#107267)

In degenerate but legal inputs, we can have functions that have no source
locations at all -- all the DebugLocs attached to i

[DWARF] Emit a minimal line-table for totally empty functions (#107267)

In degenerate but legal inputs, we can have functions that have no source
locations at all -- all the DebugLocs attached to instructions are empty.
LLVM didn't produce any source location for the function; with this patch
it will at least emit the function-scope source location. Demonstrated by
empty-line-info.ll

The XCOFF test modified has similar symptoms -- with this patch, the size
of the ".dwline" section grows a bit, thus shifting some of the file
internal offsets, which I've updated.

show more ...

[DWARF] Identify prologue_end by instruction rather than DILocation (#107264)

Currently, we identify the end of the prologue as being "the instruction
that first has *this* DebugLoc". It works well

[DWARF] Identify prologue_end by instruction rather than DILocation (#107264)

Currently, we identify the end of the prologue as being "the instruction
that first has *this* DebugLoc". It works well enough, but I feel
identifying a position in a function is best communicated by a
MachineInstr. Plus, I've got some patches coming that depend upon this.

show more ...

[DWARF] Don't search scope chain to find DISubprogram for prologues (#107261)

Seemingly this goes back to fd07a2a in 2015 -- I anticipate that back
then the metadata layout was radically different.

[DWARF] Don't search scope chain to find DISubprogram for prologues (#107261)

Seemingly this goes back to fd07a2a in 2015 -- I anticipate that back
then the metadata layout was radically different. But nowadays at least, we
can just directly look up the subprogram.

show more ...

Reapply "[DebugInfo][DWARF] Set is_stmt on first non-line-0 instruction in BB (#105524)"

Fixes the previous buildbot error by adding an explicit triple to the test,
ensuring that llc can produce a v

Reapply "[DebugInfo][DWARF] Set is_stmt on first non-line-0 instruction in BB (#105524)"

Fixes the previous buildbot error by adding an explicit triple to the test,
ensuring that llc can produce a valid object file.

This reverts commit 926f0979af4f6172d4ed3dea5603aa97c800bef1.

show more ...

Revert "[DebugInfo][DWARF] Set is_stmt on first non-line-0 instruction in BB (#105524)"

Reverted (along with the NFC followup fix) due to buildbot failure:
https://lab.llvm.org/buildbot/#/builders/1

Revert "[DebugInfo][DWARF] Set is_stmt on first non-line-0 instruction in BB (#105524)"

Reverted (along with the NFC followup fix) due to buildbot failure:
https://lab.llvm.org/buildbot/#/builders/160/builds/4142

This reverts commit 3ef37e2f8f672393ee409fde8309198df0981735, and commit
616f7d3d4f6d9bea6f776e357c938847e522a681.

show more ...

[DebugInfo][DWARF] Set is_stmt on first non-line-0 instruction in BB (#105524)

Fixes: https://github.com/llvm/llvm-project/issues/104695

This patch adds the is_stmt flag to line table entries for

[DebugInfo][DWARF] Set is_stmt on first non-line-0 instruction in BB (#105524)

Fixes: https://github.com/llvm/llvm-project/issues/104695

This patch adds the is_stmt flag to line table entries for the first
instruction with a non-0 line location in each basic block, to ensure
that it will be used for stepping even if the last instruction in the
previous basic block had the same line number; this is important for
cases where the new BB is reachable from BBs other than the preceding
block.

show more ...

[DebugInfo] (Always) include the dwo name in the hash (#100375)

Since ce0c205813c74b4225180ac8a6e40fd52ea88229, we are doing that if a
single (LTO) compilation contains more than one compile unit,

[DebugInfo] (Always) include the dwo name in the hash (#100375)

Since ce0c205813c74b4225180ac8a6e40fd52ea88229, we are doing that if a
single (LTO) compilation contains more than one compile unit, but the
same thing can happen if the non-lto and single-cu lto compilations,
typically when the CU ends up (nearly) empty. In my case, this happened
when LTO emptied two compile units.

Note that the source file name is already a part of the hash, so this
can only happen when a single file is compiled and linked twice into the
same application (most likely with different preprocessor defintiions).
While not exactly common, this pattern is used by some C code to
implement "templates".

The 2017 patch already hinted at the possibility of doing this
unconditionally, and this patch implements that. While the DWARF spec
hints at the option of using the type signature hashing algorithm for
the DWO_id purposes, AFAICT it does not actually require it, so I
believe this change is still conforming.

The relevant section of the spec is in Section 3.1.2 "Skeleton
Compilation Unit Entries" (in non-normative text):

```
The means of determining a compilation unit ID does not need to be
similar or related to the means of determining a type unit signature.
However, it should be suitable for detecting file version skew or other
kinds of mismatched files and for looking up a full split unit in a
DWARF package file (see Section 7.3.5 on page 190).
```

show more ...

[DWARF] Emit line 0 source locations for BB padding nops (#99496)

This patch makes LLVM emit line 0 source locations for nops emitted as
basic block padding.

---------

Co-authored-by: Orlando

[DWARF] Emit line 0 source locations for BB padding nops (#99496)

This patch makes LLVM emit line 0 source locations for nops emitted as
basic block padding.

---------

Co-authored-by: Orlando Cazalet-Hyams <orlando.hyams@sony.com>

show more ...