[MC,CodeView] Postpone MCDataFragment creation to finish time

`StrTabFragment` created due to `.cv_stringtable` is not placed directly
into a section. This requires a funky ~CodeViewContext and does

[MC,CodeView] Postpone MCDataFragment creation to finish time

`StrTabFragment` created due to `.cv_stringtable` is not placed directly
into a section. This requires a funky ~CodeViewContext and does not fit
well with the future that moves MCFragment storage out-of-line.

show more ...

[MC] Decrease direct access to getContents()

to make it easier to store fragment contents out-of-line. Loosely based
on Alexis Engelke's prototype.

[LLVM] Use {} instead of std::nullopt to initialize empty ArrayRef (#109133)

It is almost always simpler to use {} instead of std::nullopt to
initialize an empty ArrayRef. This patch changes all oc

[LLVM] Use {} instead of std::nullopt to initialize empty ArrayRef (#109133)

It is almost always simpler to use {} instead of std::nullopt to
initialize an empty ArrayRef. This patch changes all occurrences I could
find in LLVM itself. In future the ArrayRef(std::nullopt_t) constructor
could be deprecated or removed.

show more ...

MCCodeView: replace the MCAsmLayout parameter with MCAssembler

MCExpr::evaluateKnownAbsolute: replace the MCAsmLayout parameter with MCAssembler

and add a comment.

[MC] Allocate MCFragment with a bump allocator

#95197 and 75006466296ed4b0f845cbbec4bf77c21de43b40 eliminated all raw
`new MCXXXFragment`. We can now place fragments in a bump allocator.
In addition

[MC] Allocate MCFragment with a bump allocator

#95197 and 75006466296ed4b0f845cbbec4bf77c21de43b40 eliminated all raw
`new MCXXXFragment`. We can now place fragments in a bump allocator.
In addition, remove the dead `Kind == FragmentType(~0)` condition.

~CodeViewContext may call `StrTabFragment->destroy()` and need to be
reset before `FragmentAllocator.Reset()`.
Tested by llvm/test/MC/COFF/cv-compiler-info.ll using asan.

Pull Request: https://github.com/llvm/llvm-project/pull/96402

show more ...

[MC] Add MCFragment allocation helpers

`allocFragment` might be changed to a placement new when the allocation
strategy changes.

`allocInitialFragment` is to deduplicate the following pattern
```

[MC] Add MCFragment allocation helpers

`allocFragment` might be changed to a placement new when the allocation
strategy changes.

`allocInitialFragment` is to deduplicate the following pattern
```
auto *F = new MCDataFragment();
Result->addFragment(*F);
F->setParent(Result);
```

Pull Request: https://github.com/llvm/llvm-project/pull/95197

show more ...

Use llvm::endianness::{big,little,native} (NFC)

Note that llvm::support::endianness has been renamed to
llvm::endianness while becoming an enum class as opposed to an
enum. This patch replaces suppo

Use llvm::endianness::{big,little,native} (NFC)

Note that llvm::support::endianness has been renamed to
llvm::endianness while becoming an enum class as opposed to an
enum. This patch replaces support::{big,little,native} with
llvm::endianness::{big,little,native}.

show more ...

Emit line numbers in CodeView for trailing (after `ret`) blocks from inlined functions

Issue Details:
When building up line information for CodeView debug info, LLVM attempts to gather the "range" o

Emit line numbers in CodeView for trailing (after `ret`) blocks from inlined functions

Issue Details:
When building up line information for CodeView debug info, LLVM attempts to gather the "range" of instructions within a function as these are printed together in a single record. If there is an inlined function, then those lines are attributed to the original function to enable generating `S_INLINESITE` records. However, this thus requires there to be instructions from the inlining function after the inlined function otherwise the instruction range would not include the inlined function.

Fix Details:
Include any inlined functions when finding the extent of a function in `getFunctionLineEntries`

Reviewed By: rnk

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

show more ...

[MC] Remove dead code, NFC

This code was added in 408b5e660300f9, but neither the return value nor
`Res` was used in the following code.

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

Move from llvm::makeArrayRef to ArrayRef deduction guides - llvm/ part

Use deduction guides instead of helper functions.

The only non-automatic changes have been:

1. ArrayRef(some_uint8_pointer, 0

Move from llvm::makeArrayRef to ArrayRef deduction guides - llvm/ part

Use deduction guides instead of helper functions.

The only non-automatic changes have been:

1. ArrayRef(some_uint8_pointer, 0) needs to be changed into ArrayRef(some_uint8_pointer, (size_t)0) to avoid an ambiguous call with ArrayRef((uint8_t*), (uint8_t*))
2. CVSymbol sym(makeArrayRef(symStorage)); needed to be rewritten as CVSymbol sym{ArrayRef(symStorage)}; otherwise the compiler is confused and thinks we have a (bad) function prototype. There was a few similar situation across the codebase.
3. ADL doesn't seem to work the same for deduction-guides and functions, so at some point the llvm namespace must be explicitly stated.
4. The "reference mode" of makeArrayRef(ArrayRef<T> &) that acts as no-op is not supported (a constructor cannot achieve that).

Per reviewers' comment, some useless makeArrayRef have been removed in the process.

This is a follow-up to https://reviews.llvm.org/D140896 that introduced
the deduction guides.

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

show more ...

[llvm] Use std::nullopt instead of None (NFC)

This patch mechanically replaces None with std::nullopt where the
compiler would warn if None were deprecated. The intent is to reduce
the amount of ma

[llvm] Use std::nullopt instead of None (NFC)

This patch mechanically replaces None with std::nullopt where the
compiler would warn if None were deprecated. The intent is to reduce
the amount of manual work required in migrating from Optional to
std::optional.

This is part of an effort to migrate from llvm::Optional to
std::optional:

https://discourse.llvm.org/t/deprecating-llvm-optional-x-hasvalue-getvalue-getvalueor/63716

show more ...

[Alignment][NFC] Use Align in MCStreamer::emitValueToAlignment

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

[MC] Lower case the first letter of EmitCOFF* EmitWin* EmitCV*. NFC

Cleanup LLVMMC headers

There's a few relevant forward declarations in there that may require downstream
adding explicit includes:

llvm/MC/MCContext.h no longer includes llvm/BinaryFormat/ELF.h, llv

Cleanup LLVMMC headers

There's a few relevant forward declarations in there that may require downstream
adding explicit includes:

llvm/MC/MCContext.h no longer includes llvm/BinaryFormat/ELF.h, llvm/MC/MCSubtargetInfo.h, llvm/MC/MCTargetOptions.h
llvm/MC/MCObjectStreamer.h no longer include llvm/MC/MCAssembler.h
llvm/MC/MCAssembler.h no longer includes llvm/MC/MCFixup.h, llvm/MC/MCFragment.h

Counting preprocessed lines required to rebuild llvm-project on my setup:
before: 1052436830
after: 1049293745

Which is significant and backs up the change in addition to the usual benefits of
decreasing coupling between headers and compilation units.

Discourse thread: https://discourse.llvm.org/t/include-what-you-use-include-cleanup
Differential Revision: https://reviews.llvm.org/D119244

show more ...

[llvm] Use = default (NFC)

[CodeView] Fix inline sites that are missing code offsets.

When an inline site has a starting code offset of 0, we sometimes
don't emit the starting offset.

Bug: https://bugs.llvm.org/show_bug.cgi?

[CodeView] Fix inline sites that are missing code offsets.

When an inline site has a starting code offset of 0, we sometimes
don't emit the starting offset.

Bug: https://bugs.llvm.org/show_bug.cgi?id=48377

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

show more ...

[MC][NFC] Use camelCase style for functions in MCObjectStreamer

[MC] Add MCStreamer::emitInt{8,16,32,64}

Similar to AsmPrinter::emitInt{8,16,32,64}.

[MCStreamer] De-capitalize EmitValue EmitIntValue{,InHex}

[MC] De-capitalize another set of MCStreamer::Emit* functions

Emit{ValueTo,Code}Alignment Emit{DTP,TP,GP}* EmitSymbolValue etc

[MC] De-capitalize some MCStreamer::Emit* functions

[codeview] Revert inline line table change of r362264

Testing with debuggers shows that our previous behavior was correct.
The reason I thought MSVC did things differently is that MSVC prefers to
us

[codeview] Revert inline line table change of r362264

Testing with debuggers shows that our previous behavior was correct.
The reason I thought MSVC did things differently is that MSVC prefers to
use the 0xB combined code offset and code length update opcode when
inline sites are discontiguous.

Keep the test changes, and update the llvm-pdbutil inline line table
dumper to account for this new interpretation of the opcodes.

llvm-svn: 362277

show more ...

[codeview] Fix inline line table accuracy for discontiguous segments

After improving the inline line table dumper in llvm-pdbutil and looking
at MSVC's inline line tables, it is clear that setting t

[codeview] Fix inline line table accuracy for discontiguous segments

After improving the inline line table dumper in llvm-pdbutil and looking
at MSVC's inline line tables, it is clear that setting the length of the
inlined code region does not update the code offset. This means that the
delta to the beginning of a new discontiguous inlined code region should
be calculated relative to the last code offset, excluding the length.
Implementing this is a one line fix for MC: simply don't update
LastLabel.

While I'm updating these test cases, switch them to use llvm-objdump -d
and llvm-pdbutil. This allows us to show offsets of each instruction and
correlate the line table offsets to the actual code.

llvm-svn: 362264

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