[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 ...

[FastISel][X86] Use getTypeForExtReturn in GetReturnInfo. (#80803)

The comment and code here seems to match getTypeForExtReturn. The
history shows that at the time this code was added, similar code

[FastISel][X86] Use getTypeForExtReturn in GetReturnInfo. (#80803)

The comment and code here seems to match getTypeForExtReturn. The
history shows that at the time this code was added, similar code existed
in SelectionDAGBuilder. SelectionDAGBuiler code has since been
refactored into getTypeForExtReturn.

This patch makes FastISel match SelectionDAGBuilder.

The test changes are because X86 has customization of
getTypeForExtReturn. So now we only extend returns to i8.

Stumbled onto this difference by accident.

show more ...

Fix UB in DwarfExpression::emitLegacyZExt()

A shift-left > 63 triggers a UBSAN failure. This patch kicks the can
down the road (to the consumer) by emitting a more compact
representation of the shif

Fix UB in DwarfExpression::emitLegacyZExt()

A shift-left > 63 triggers a UBSAN failure. This patch kicks the can
down the road (to the consumer) by emitting a more compact
representation of the shift computation in DWARF expressions.

Relanding (I accidentally pushed an earlier version of the patch previously).

Differential Revision: https://reviews.llvm.org/D118183

show more ...

Revert "Fix UB in DwarfExpression::emitLegacyZExt()"

This reverts commit 216002c4bb708e6d6fd1895c8ea636470961f824
while investigating bot breakage.

Fix UB in DwarfExpression::emitLegacyZExt()

A shift-left > 63 triggers a UBSAN failure. This patch kicks the can
down the road (to the consumer) by emitting a more compact
representation of the shif

Fix UB in DwarfExpression::emitLegacyZExt()

A shift-left > 63 triggers a UBSAN failure. This patch kicks the can
down the road (to the consumer) by emitting a more compact
representation of the shift computation in DWARF expressions.

Differential Revision: https://reviews.llvm.org/D118183

show more ...

Revert accidentally pushed commit. It was not yet reviewed.

"Fix UB in DwarfExpression::emitLegacyZExt()"

This reverts commit e37de5d36e3190283916604342b029859129e2a4.

Fix UB in DwarfExpression::emitLegacyZExt()

A shift-left > 63 triggers a UBSAN failure. This patch kicks the can
down the road (to the consumer) by emitting a more compact
representation of the shif

Fix UB in DwarfExpression::emitLegacyZExt()

A shift-left > 63 triggers a UBSAN failure. This patch kicks the can
down the road (to the consumer) by emitting a more compact
representation of the shift computation in DWARF expressions.

Differential Revision: https://reviews.llvm.org/D118183

show more ...

Add a DIExpression const-folder to prevent silly expressions.

It's entirely possible (because it actually happened) for a bool
variable to end up with a 256-bit DW_AT_const_value. This came about
w

Add a DIExpression const-folder to prevent silly expressions.

It's entirely possible (because it actually happened) for a bool
variable to end up with a 256-bit DW_AT_const_value. This came about
when a local bool variable was initialized from a bitfield in a
32-byte struct of bitfields, and after inlining and constant
propagation, the variable did have a constant value. The sequence of
optimizations had it carrying "i256" values around, but once the
constant made it into the llvm.dbg.value, no further IR changes could
affect it.

Technically the llvm.dbg.value did have a DIExpression to reduce it
back down to 8 bits, but the compiler is in no way ready to emit an
oversized constant *and* a DWARF expression to manipulate it.
Depending on the circumstances, we had either just the very fat bool
value, or an expression with no starting value.

The sequence of optimizations that led to this state did seem pretty
reasonable, so the solution I came up with was to invent a DWARF
constant expression folder. Currently it only does convert ops, but
there's no reason it couldn't do other ops if that became useful.

This broke three tests that depended on having convert ops survive
into the DWARF, so I added an operator that would abort the folder to
each of those tests.

Differential Revision: https://reviews.llvm.org/D106915

show more ...

DebugInfo: Add some missing explicit target triples.

Based on D91043 by Luís Marques. Thanks Luís!

Differential Revision: https://reviews.llvm.org/D91043

Revert "[DebugInfo] Shorten legacy [s|z]ext dwarf expressions"

This reverts commit 2ce36ebca544dd71075a7818ff4070da5667603b. It depends
on https://reviews.llvm.org/D89838, which needs to be reverted.

[DebugInfo] Shorten legacy [s|z]ext dwarf expressions

Take advantage of the emitConstu helper to emit slightly shorter dwarf
expressions to implement legacy [s|z]ext operations.

llvm-dwarfdump: Support verbose printing DW_OP_convert to print the CU local offset before the resolved absolute offset

DebugInfo: Hash DIE referevences (DW_OP_convert) when computing Split DWARF signatures

DebugInfo: Tidy up test for more portability to MachO and Windows

*fingers crossed*

DebugInfo: Use llc rather than %llc_dwarf when also hardcoding a target triple

DWARFv5: Disable DW_OP_convert for configurations that don't yet support it

Testing reveals that lldb and gdb have some problems with supporting
DW_OP_convert - gdb with Split DWARF tries to resolve

DWARFv5: Disable DW_OP_convert for configurations that don't yet support it

Testing reveals that lldb and gdb have some problems with supporting
DW_OP_convert - gdb with Split DWARF tries to resolve the CU-relative
DIE offset relative to the skeleton DIE. lldb tries to treat the offset
as absolute, which judging by the llvm-dsymutil support for
DW_OP_convert, I guess works OK in MachO? (though probably llvm-dsymutil
is producing invalid DWARF by resolving the relative reference to an
absolute one?).

Specifically this disables DW_OP_convert usage in DWARFv5 if:
* Tuning for GDB and using Split DWARF
* Tuning for LLDB and not targeting MachO

show more ...

DebugInfo: Stabilize DW_OP_convert tests so they don't depend on register allocation, etc

DebugInfo: convert-debugloc.ll generalize to run on ppc64le

This target produces a location list for the location, so split the
match between lines to allow for a location list match.

DebugInfo: convert-debugloc.ll remove erroneous CHECK

DebugInfo: Generalize convert-debugloc.ll to run for multiple target architectures

This test was overly constrained & hardcoded only to x86-linux-gnu -
generalize the test & remove the hardcoded tar

DebugInfo: Generalize convert-debugloc.ll to run for multiple target architectures

This test was overly constrained & hardcoded only to x86-linux-gnu -
generalize the test & remove the hardcoded target triple.

show more ...

RegAllocFast: Improve hinting heuristic

Trace through multiple COPYs when looking for a physreg source. Add
hinting for vregs that will be copied into physregs (we only hinted
for vregs getting copi

RegAllocFast: Improve hinting heuristic

Trace through multiple COPYs when looking for a physreg source. Add
hinting for vregs that will be copied into physregs (we only hinted
for vregs getting copied to a physreg previously). Give hinted a
register a bonus when deciding which value to spill. This is part of
my rewrite regallocfast series. In fact this one doesn't even have an
effect unless you also flip the allocation to happen from back to
front of a basic block. Nonetheless it helps to split this up to ease
review of D52010

Patch by Matthias Braun

llvm-svn: 360887

show more ...

DWARF v5: emit DW_AT_addr_base if DW_AT_low_pc references .debug_addr

The condition !AddrPool.empty() is tested before attachRangesOrLowHighPC(), which may add an entry to AddrPool. We emit DW_AT_lo

DWARF v5: emit DW_AT_addr_base if DW_AT_low_pc references .debug_addr

The condition !AddrPool.empty() is tested before attachRangesOrLowHighPC(), which may add an entry to AddrPool. We emit DW_AT_low_pc (DW_FORM_addrx) but may incorrectly omit DW_AT_addr_base for LineTablesOnly. This can be easily reproduced:

clang -gdwarf-5 -gmlt -c a.cc

Fix this by moving !AddrPool.empty() below.

This was discovered while investigating an lld crash (fixed by D61889) on such object files: ld.lld --gdb-index a.o

Reviewed By: probinson

Differential Revision: https://reviews.llvm.org/D61891

llvm-svn: 360678

show more ...

[DebugInfo] Move test files added in r356451

Moved the X86 dependant .ll tests added in r356451 from
test/DebugInfo/Generic to test/DebugInfo/X86.

llvm-svn: 356460