hwasan: add tag_offset DWARF attribute to optimized debug info

Summary:
Support alloca-referencing dbg.value in hwasan instrumentation.
Update AsmPrinter to emit DW_AT_LLVM_tag_offset when location

hwasan: add tag_offset DWARF attribute to optimized debug info

Summary:
Support alloca-referencing dbg.value in hwasan instrumentation.
Update AsmPrinter to emit DW_AT_LLVM_tag_offset when location is in
loclist format.

Reviewers: pcc

Subscribers: srhines, aprantl, hiraditya, llvm-commits

Tags: #llvm

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

show more ...

DebugInfo: Move loclist base address from DwarfFile to DebugLocStream

There's no need to have more than one of these (there can be two
DwarfFiles - one for the .o, one for the .dwo - but only one lo

DebugInfo: Move loclist base address from DwarfFile to DebugLocStream

There's no need to have more than one of these (there can be two
DwarfFiles - one for the .o, one for the .dwo - but only one loc/loclist
section (either in the .o or the .dwo) & certainly one per
DebugLocStream, which is currently singular in DwarfDebug)

llvm-svn: 375183

show more ...

Change Comments SmallVector to std::vector in DebugLocStream [NFC]

This changes the 32-element SmallVector to a std::vector. When building
a RelWithDebInfo clang-8 binary, the average size of the ve

Change Comments SmallVector to std::vector in DebugLocStream [NFC]

This changes the 32-element SmallVector to a std::vector. When building
a RelWithDebInfo clang-8 binary, the average size of the vector was
~10000, so it does not seem very beneficial or practical to use a small
vector for that.

The DWARFBytes SmallVector grows in the same way as Comments, so perhaps
that also should be changed to a purely dynamically allocated structure,
but that requires some more code changes, so I let that remain as a
SmallVector for now.

llvm-svn: 374871

show more ...

DebugInfo: Rename DebugLocStream::Entry::Begin/EndSym to just Begin/End

Brings this struct in line with the RangeSpan class so they might
eventually be used by common template code for generating ra

DebugInfo: Rename DebugLocStream::Entry::Begin/EndSym to just Begin/End

Brings this struct in line with the RangeSpan class so they might
eventually be used by common template code for generating range/loc
lists with less duplicate code.

llvm-svn: 373540

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

Remove \brief commands from doxygen comments.

We've been running doxygen with the autobrief option for a couple of
years now. This makes the \brief markers into our comments
redundant. Since they ar

Remove \brief commands from doxygen comments.

We've been running doxygen with the autobrief option for a couple of
years now. This makes the \brief markers into our comments
redundant. Since they are a visual distraction and we don't want to
encourage more \brief markers in new code either, this patch removes
them all.

Patch produced by

for i in $(git grep -l '\\brief'); do perl -pi -e 's/\\brief //g' $i & done

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

llvm-svn: 331272

show more ...

Sort the remaining #include lines in include/... and lib/....

I did this a long time ago with a janky python script, but now
clang-format has built-in support for this. I fed clang-format every
line

Sort the remaining #include lines in include/... and lib/....

I did this a long time ago with a janky python script, but now
clang-format has built-in support for this. I fed clang-format every
line with a #include and let it re-sort things according to the precise
LLVM rules for include ordering baked into clang-format these days.

I've reverted a number of files where the results of sorting includes
isn't healthy. Either places where we have legacy code relying on
particular include ordering (where possible, I'll fix these separately)
or where we have particular formatting around #include lines that
I didn't want to disturb in this patch.

This patch is *entirely* mechanical. If you get merge conflicts or
anything, just ignore the changes in this patch and run clang-format
over your #include lines in the files.

Sorry for any noise here, but it is important to keep these things
stable. I was seeing an increasing number of patches with irrelevant
re-ordering of #include lines because clang-format was used. This patch
at least isolates that churn, makes it easy to skip when resolving
conflicts, and gets us to a clean baseline (again).

llvm-svn: 304787

show more ...

AsmPrinter: Don't emit empty .debug_loc entries

If we don't know how to represent a .debug_loc entry, skip the entry
entirely rather than emitting an empty one. Similarly, if a .debug_loc
list has

AsmPrinter: Don't emit empty .debug_loc entries

If we don't know how to represent a .debug_loc entry, skip the entry
entirely rather than emitting an empty one. Similarly, if a .debug_loc
list has no entries, don't create the list.

We still want to create the variables, just in an optimized-out form
that doesn't have a DW_AT_location.

llvm-svn: 240244

show more ...

Fixed/added namespace ending comments using clang-tidy. NFC

The patch is generated using this command:

tools/clang/tools/extra/clang-tidy/tool/run-clang-tidy.py -fix \
-checks=-*,llvm-namespace-c

Fixed/added namespace ending comments using clang-tidy. NFC

The patch is generated using this command:

tools/clang/tools/extra/clang-tidy/tool/run-clang-tidy.py -fix \
-checks=-*,llvm-namespace-comment -header-filter='llvm/.*|clang/.*' \
llvm/lib/


Thanks to Eugene Kosov for the original patch!

llvm-svn: 240137

show more ...

Don't generate comments in the DebugLocStream unless required. NFC.

The ByteStreamer here wasn't taking account of whether the asm streamer was text based and verbose. Only with that combination s

Don't generate comments in the DebugLocStream unless required. NFC.

The ByteStreamer here wasn't taking account of whether the asm streamer was text based and verbose. Only with that combination should we emit comments.

This change makes sure that we only actually convert a Twine to a string using Twine::str() if we need the comment. This saves about 10000 small allocations on a test case involving the verify-use_list-order bitcode going through llc with debug info.

Note, this is NFC as the comments would ultimately never be emitted unless required.

Reviewed by Duncan Exon Smith and David Blaikie.

llvm-svn: 237851

show more ...

AsmPrinter: Create a unified .debug_loc stream

This commit removes `DebugLocList` and replaces it with
`DebugLocStream`.

- `DebugLocEntry` no longer contains its byte/comment streams.
- The `De

AsmPrinter: Create a unified .debug_loc stream

This commit removes `DebugLocList` and replaces it with
`DebugLocStream`.

- `DebugLocEntry` no longer contains its byte/comment streams.
- The `DebugLocEntry` list for a variable/inlined-at pair is allocated
on the stack, and released right after `DebugLocEntry::finalize()`
(possible because of the refactoring in r231023). Now, only one
list is in memory at a time now.
- There's a single unified stream for the `.debug_loc` section that
persists, stored in the new `DebugLocStream` data structure.

The last point is important: this collapses the nested `SmallVector<>`s
from `DebugLocList` into unified streams. We previously had something
like the following:

vec<tuple<Label, CU,
vec<tuple<BeginSym, EndSym,
vec<Value>,
vec<char>,
vec<string>>>>>

A `SmallVector` can avoid allocations, but is statically fairly large
for a vector: three pointers plus the size of the small storage, which
is the number of elements in small mode times the element size).
Nesting these is expensive, since an inner vector's size contributes to
the element size of an outer one. (Nesting any vector is expensive...)

In the old data structure, the outer vector's *element* size was 632B,
excluding allocation costs for when the middle and inner vectors
exceeded their small sizes. 312B of this was for the "three" pointers
in the vector-tree beneath it. If you assume 1M functions with an
average of 10 variable/inlined-at pairs each (in an LTO scenario),
that's almost 6GB (besides inner allocations), with almost 3GB for the
"three" pointers.

This came up in a heap profile a little while ago of a `clang -flto -g`
bootstrap, with `DwarfDebug::collectVariableInfo()` using something like
10-15% of the total memory.

With this commit, we have:

tuple<vec<tuple<Label, CU, Offset>>,
vec<tuple<BeginSym, EndSym, Offset, Offset>>,
vec<char>,
vec<string>>

The offsets are used to create `ArrayRef` slices of adjacent
`SmallVector`s. This reduces the number of vectors to four (unrelated
to the number of variable/inlined-at pairs), and caps the number of
allocations at the same number.

Besides saving memory and limiting allocations, this is NFC.

I don't know my way around this code very well yet, but I wonder if we
could go further: why stream to a side-table, instead of directly to the
output stream?

llvm-svn: 235229

show more ...