Revert "[MS] Emit S_HEAPALLOCSITE debug info" because of ToTWin64(db)
buildbot failure.

This reverts commit d07d6d617713bececf57f3547434dd52f0f13f9e and
c774f687b6880484a126ed3e3d737e74c926f0ae.

ll

Revert "[MS] Emit S_HEAPALLOCSITE debug info" because of ToTWin64(db)
buildbot failure.

This reverts commit d07d6d617713bececf57f3547434dd52f0f13f9e and
c774f687b6880484a126ed3e3d737e74c926f0ae.

llvm-svn: 359034

show more ...

[MS] Emit S_HEAPALLOCSITE debug info

Summary:
This emits labels around heapallocsite calls and S_HEAPALLOCSITE debug
info in codeview. Currently only changes FastISel, so emitting labels still
needs

[MS] Emit S_HEAPALLOCSITE debug info

Summary:
This emits labels around heapallocsite calls and S_HEAPALLOCSITE debug
info in codeview. Currently only changes FastISel, so emitting labels still
needs to be implemented in SelectionDAG.

Reviewers: hans, rnk

Subscribers: aprantl, hiraditya, cfe-commits, llvm-commits

Tags: #clang, #llvm

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

llvm-svn: 358783

show more ...

[DebugInfo] Improve handling of clobbered fragments

Summary:
Currently the DbgValueHistorymap only keeps track of clobbered registers
for the last debug value that it has encountered. This could lea

[DebugInfo] Improve handling of clobbered fragments

Summary:
Currently the DbgValueHistorymap only keeps track of clobbered registers
for the last debug value that it has encountered. This could lead to
preceding register-described debug values living on longer in the
location lists than they should. See PR40283 for an example. This
patch does not introduce tracking of multiple registers, but changes
the DbgValueHistoryMap structure to allow for that in a follow-up
patch. This patch is not NFC, as it at least fixes two bugs in
DwarfDebug (both are covered in the new clobbered-fragments.mir test):

* If a debug value was clobbered (its End pointer set), the value would
still be added to OpenRanges, meaning that the succeeding location list
entries could potentially contain stale values.

* If a debug value was clobbered, and there were non-overlapping
fragments that were still live after the clobbering, DwarfDebug would
not create a location list entry starting directly after the
clobbering instruction. This meant that the location list could have
a gap until the next debug value for the variable was encountered.

Before this patch, the history map was represented by <Begin, End>
pairs, where a new pair was created for each new debug value. When
dealing with partially overlapping register-described debug values, such
as in the following example:

DBG_VALUE $reg2, $noreg, !1, !DIExpression(DW_OP_LLVM_fragment, 32, 32)
[...]
DBG_VALUE $reg3, $noreg, !1, !DIExpression(DW_OP_LLVM_fragment, 64, 32)
[...]
$reg2 = insn1
[...]
$reg3 = insn2

the history map would then contain the entries `[<DV1, insn1>, [<DV2, insn2>]`.
This would leave it up to the users of the map to be aware of
the relative order of the instructions, which e.g. could make
DwarfDebug::buildLocationList() needlessly complex. Instead, this patch
makes the history map structure monotonically increasing by dropping the
End pointer, and replacing that with explicit clobbering entries in the
vector. Each debug value has an "end index", which if set, points to the
entry in the vector that ends the debug value. The ending entry can
either be an overlapping debug value, or an instruction which clobbers
the register that the debug value is described by. The ending entry's
instruction can thus either be excluded or included in the debug value's
range. If the end index is not set, the debug value that the entry
introduces is valid until the end of the function.

Changes to test cases:

* DebugInfo/X86/pieces-3.ll: The range of the first DBG_VALUE, which
describes that the fragment (0, 64) is located in RDI, was
incorrectly ended by the clobbering of RAX, which the second
(non-overlapping) DBG_VALUE was described by. With this patch we
get a second entry that only describes RDI after that clobbering.

* DebugInfo/ARM/partial-subreg.ll: This test seems to indiciate a bug
in LiveDebugValues that is caused by it not being aware of fragments.
I have added some comments in the test case about that. Also, before
this patch DwarfDebug would incorrectly include a register-described
debug value from a preceding block in a location list entry.

Reviewers: aprantl, probinson, dblaikie, rnk, bjope

Reviewed By: aprantl

Subscribers: javed.absar, kristof.beyls, jdoerfert, llvm-commits

Tags: #debug-info, #llvm

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

llvm-svn: 358072

show more ...

[DebugInfo] Rename DbgValueHistoryMap::{InstrRange -> Entry}, NFC

Summary:
In an upcoming commit the history map will be changed so that it
contains explicit entries for instructions that clobber pr

[DebugInfo] Rename DbgValueHistoryMap::{InstrRange -> Entry}, NFC

Summary:
In an upcoming commit the history map will be changed so that it
contains explicit entries for instructions that clobber preceding debug
values, rather than Begin- End range pairs, so generalize the name to
"Entry".

Also, prefix the iterator variable names in buildLocationList() with
"E". In an upcoming commit the entry will have query functions such as
"isD(e)b(u)gValue", which could at a glance make one confuse it for
iterations over MachineInstrs, so make the iterator names a bit more
distinct to avoid that.

Reviewers: aprantl

Reviewed By: aprantl

Subscribers: llvm-commits

Tags: #llvm

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

llvm-svn: 358060

show more ...

[DebugInfo] Make InstrRange into a class, NFC

Summary:
Replace use of std::pair by creating a class for the debug value
instruction ranges instead. This is a preparatory refactoring for
improving ha

[DebugInfo] Make InstrRange into a class, NFC

Summary:
Replace use of std::pair by creating a class for the debug value
instruction ranges instead. This is a preparatory refactoring for
improving handling of clobbered fragments.

In an upcoming commit the Begin pointer will become a PointerIntPair, so
it will be cleaner to have a getter for that.

Reviewers: aprantl

Subscribers: llvm-commits

Tags: #llvm

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

llvm-svn: 358059

show more ...

[IR] Refactor attribute methods in Function class (NFC)

Rename the functions that query the optimization kind attributes.

Differential revision: https://reviews.llvm.org/D60287

llvm-svn: 357731

[IR] Create new method in `Function` class (NFC)

Create method `optForNone()` testing for the function level equivalent of
`-O0` and refactor appropriately.

Differential revision: https://reviews.l

[IR] Create new method in `Function` class (NFC)

Create method `optForNone()` testing for the function level equivalent of
`-O0` and refactor appropriately.

Differential revision: https://reviews.llvm.org/D59852

llvm-svn: 357638

show more ...

Add Swift enumerator value for CodeView::SourceLanguage

Summary:
Swift now generates PDBs for debugging on Windows. llvm and lldb
need a language enumerator value too properly handle the output
emit

Add Swift enumerator value for CodeView::SourceLanguage

Summary:
Swift now generates PDBs for debugging on Windows. llvm and lldb
need a language enumerator value too properly handle the output
emitted by swiftc.

Subscribers: jdoerfert, llvm-commits

Tags: #llvm

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

llvm-svn: 355882

show more ...

[CodeView] Emit HasConstructorOrDestructor class option for non-trivial constructors

Reviewers: zturner, rnk, llvm-commits, aleksandr.urakov

Reviewed By: zturner, rnk

Subscribers: jdoerfert, majne

[CodeView] Emit HasConstructorOrDestructor class option for non-trivial constructors

Reviewers: zturner, rnk, llvm-commits, aleksandr.urakov

Reviewed By: zturner, rnk

Subscribers: jdoerfert, majnemer, asmith

Tags: #llvm

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

llvm-svn: 354841

show more ...

[CodeView] Allow empty types in member functions

Summary:
`CodeViewDebug::lowerTypeMemberFunction` used to default to a `Void`
return type if the function's type array was empty. After D54667, it
st

[CodeView] Allow empty types in member functions

Summary:
`CodeViewDebug::lowerTypeMemberFunction` used to default to a `Void`
return type if the function's type array was empty. After D54667, it
started blindly indexing the 0th item for the return type, which fails
in `getOperand` for empty arrays if assertions are enabled.

This patch restores the `Void` return type for empty type arrays, and
adds a test generated by Rust in line-only debuginfo mode.

Reviewers: zturner, rnk

Reviewed By: rnk

Subscribers: hiraditya, JDevlieghere, llvm-commits

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

llvm-svn: 351910

show more ...

Update the file headers across all of the LLVM projects in the monorepo
to reflect the new license.

We understand that people may be surprised that we're moving the header
entirely to discuss the ne

Update the file headers across all of the LLVM projects in the monorepo
to reflect the new license.

We understand that people may be surprised that we're moving the header
entirely to discuss the new license. We checked this carefully with the
Foundation's lawyer and we believe this is the correct approach.

Essentially, all code in the project is now made available by the LLVM
project under our new license, so you will see that the license headers
include that license only. Some of our contributors have contributed
code under our old license, and accordingly, we have retained a copy of
our old license notice in the top-level files in each project and
repository.

llvm-svn: 351636

show more ...

[codeview] Check if this 'this' type of a method is a pointer

Fixes crash reported after r347354 for frontends that don't always emit
'this' pointers for methods. Now we will silently produce debug

[codeview] Check if this 'this' type of a method is a pointer

Fixes crash reported after r347354 for frontends that don't always emit
'this' pointers for methods. Now we will silently produce debug info
that makes functions like this look like static methods, which seems
reasonable.

llvm-svn: 350073

show more ...

[CodeView] Emit global variables within lexical scopes to limit visibility

Emit static locals within the correct lexical scope so variables with the same
name will not confuse the debugger into gett

[CodeView] Emit global variables within lexical scopes to limit visibility

Emit static locals within the correct lexical scope so variables with the same
name will not confuse the debugger into getting the wrong value.

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

llvm-svn: 349777

show more ...

[codeview] Update comment on aligning symbol records

llvm-svn: 349433

[codeview] Align symbol records to save 441MB during linking clang.pdb

In PDBs, symbol records must be aligned to four bytes. However, in the
object file, symbol records may not be aligned. MSVC doe

[codeview] Align symbol records to save 441MB during linking clang.pdb

In PDBs, symbol records must be aligned to four bytes. However, in the
object file, symbol records may not be aligned. MSVC does not pad out
symbol records to make sure they are aligned. That means the linker has
to do extra work to insert the padding. Currently, LLD calculates the
required space with alignment, and copies each record one at a time
while padding them out to the correct size. It has a fast path that
avoids this copy when the records are already aligned.

This change fixes a bug in that codepath so that the copy is actually
saved, and tweaks LLVM's symbol record emission to align symbol records.
Here's how things compare when doing a plain clang Release+PDB build:
- objs are 0.65% bigger (negligible)
- link is 3.3% faster (negligible)
- saves allocating 441MB
- new LLD high water mark is ~1.05GB

llvm-svn: 349431

show more ...

[codeview] Add begin/endSymbolRecord helpers, NFC

Previously beginning a symbol record was excessively verbose. Now it's a
bit simpler. This follows the same pattern as begin/endCVSubsection.

llvm-

[codeview] Add begin/endSymbolRecord helpers, NFC

Previously beginning a symbol record was excessively verbose. Now it's a
bit simpler. This follows the same pattern as begin/endCVSubsection.

llvm-svn: 349205

show more ...

[codeview] Look through typedefs in getCompleteTypeIndex

Summary:
Any time a symbol record, whether it's S_UDT, S_LOCAL, or S_[GL]DATA32,
references a record type, it should use the complete type in

[codeview] Look through typedefs in getCompleteTypeIndex

Summary:
Any time a symbol record, whether it's S_UDT, S_LOCAL, or S_[GL]DATA32,
references a record type, it should use the complete type index, even if
there's a typedef in the way.

Fixes the compiler part of PR39853.

Reviewers: zturner, aganea

Subscribers: hiraditya, arphaman, llvm-commits

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

llvm-svn: 348902

show more ...

Delete dead code introduced in r347354.

ParentTy is never used other than an assignment, and since it is a
pointer, there is no side effect. Some versions of GCC notice and warn
on this.

Change-Id:

Delete dead code introduced in r347354.

ParentTy is never used other than an assignment, and since it is a
pointer, there is no side effect. Some versions of GCC notice and warn
on this.

Change-Id: I37dc1a18c7b58040419afb803621de13d8904a8f
llvm-svn: 347581

show more ...

[CodeView] Add support for ref-qualified member functions.

When you have a member function with a ref-qualifier, for example:

struct Foo {
void Func() &;
void Func2() &&;
};

clang-cl was not e

[CodeView] Add support for ref-qualified member functions.

When you have a member function with a ref-qualifier, for example:

struct Foo {
void Func() &;
void Func2() &&;
};

clang-cl was not emitting this information. Doing so is a bit
awkward, because it's not a property of the LF_MFUNCTION type, which
is what you'd expect. Instead, it's a property of the this pointer
which is actually an LF_POINTER. This record has an attributes
bitmask on it, and our handling of this bitmask was all wrong. We
had some parts of the bitmask defined incorrectly, but importantly
for this bug, we didn't know about these extra 2 bits that represent
the ref qualifier at all.

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

llvm-svn: 347354

show more ...

[CodeView] Mark this pointers as const.

This is for compatibility with MSVC, which also marks this pointers
as being const-qualified.

Fixes llvm.org/pr36526

Differential Revision: https://reviews.

[CodeView] Mark this pointers as const.

This is for compatibility with MSVC, which also marks this pointers
as being const-qualified.

Fixes llvm.org/pr36526

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

llvm-svn: 347353

show more ...

[codeview] Expose -gcodeview-ghash for global type hashing

Summary:
Experience has shown that the functionality is useful. It makes linking
optimized clang with debug info for me a lot faster, 20s t

[codeview] Expose -gcodeview-ghash for global type hashing

Summary:
Experience has shown that the functionality is useful. It makes linking
optimized clang with debug info for me a lot faster, 20s to 13s. The
type merging phase of PDB writing goes from 10s to 3s.

This removes the LLVM cl::opt and replaces it with a metadata flag.

After this change, users can do the following to use ghash:
- add -gcodeview-ghash to compiler flags
- replace /DEBUG with /DEBUG:GHASH in linker flags

Reviewers: zturner, hans, thakis, takuto.ikuta

Subscribers: aprantl, hiraditya, JDevlieghere, llvm-commits

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

llvm-svn: 347072

show more ...

[codeview] Let the X86 backend tell us the VFRAME offset adjustment

Use MachineFrameInfo's OffsetAdjustment field to pass this information
from the target to CodeViewDebug.cpp. The X86 backend doesn

[codeview] Let the X86 backend tell us the VFRAME offset adjustment

Use MachineFrameInfo's OffsetAdjustment field to pass this information
from the target to CodeViewDebug.cpp. The X86 backend doesn't use it for
any other purpose.

This fixes PR38857 in the case where there is a non-aligned quantity of
CSRs and a non-aligned quantity of locals.

llvm-svn: 346062

show more ...

[CodeView] Emit the correct TypeIndex for std::nullptr_t.

The TypeIndex used by cl.exe is 0x103, which indicates a SimpleTypeMode
of NearPointer (note the absence of the bitness, normally pointers u

[CodeView] Emit the correct TypeIndex for std::nullptr_t.

The TypeIndex used by cl.exe is 0x103, which indicates a SimpleTypeMode
of NearPointer (note the absence of the bitness, normally pointers use a
mode of NearPointer32 or NearPointer64) and a SimpleTypeKind of void.
So this is basically a void*, but without a specified size, which makes
sense given how std::nullptr_t is defined.

clang-cl was actually not emitting *anything* for this. Instead, when we
encountered std::nullptr_t in a DIType, we would actually just emit a
TypeIndex of 0, which is obviously wrong.

std::nullptr_t in DWARF is represented as a DW_TAG_unspecified_type with
a name of "decltype(nullptr)", so we add that logic along with a test,
as well as an update to the dumping code so that we no longer print
void* when dumping 0x103 (which would previously treat Void/NearPointer
no differently than Void/NearPointer64).

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

llvm-svn: 345811

show more ...

MachineModuleInfo: Initialize DbgInfoAvailable depending on debug_cus existing

Before this patch DbgInfoAvailable was set to true in
DwarfDebug::beginModule() or CodeViewDebug::CodeViewDebug(). This

MachineModuleInfo: Initialize DbgInfoAvailable depending on debug_cus existing

Before this patch DbgInfoAvailable was set to true in
DwarfDebug::beginModule() or CodeViewDebug::CodeViewDebug(). This made
MIR testing weird since passes would suddenly stop dealing with debug
info just because we stopped the pipeline before the debug printers.

This patch changes the logic to initialize DbgInfoAvailable based on the
fact that debug_compile_units exist in the llvm Module. The debug
printers may then override it with false in case of debug printing being
disabled.

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

llvm-svn: 345740

show more ...

[codeview] Emit S_BUILDINFO and LF_BUILDINFO with cwd and source file

Summary: We can fill in the command line and compiler path later if we want.

Reviewers: zturner

Subscribers: hiraditya, llvm-c

[codeview] Emit S_BUILDINFO and LF_BUILDINFO with cwd and source file

Summary: We can fill in the command line and compiler path later if we want.

Reviewers: zturner

Subscribers: hiraditya, llvm-commits

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

llvm-svn: 344393

show more ...