llvm-project.git/llvm/unittests/CodeGen/TestAsmPrinter.cpp, branch users/nico/python-2

[TargetRegistry] Accept Triple in createTargetMachine() (NFC) (#130940)

2025-03-12T16:35:09+00:00

This avoids doing a Triple -> std::string -> Triple round trip in lots
of places, now that the Module stores a Triple.

[NFC][TargetParser] Remove llvm/ADT/Triple.h

2023-02-07T12:39:46+00:00

I also ran `git clang-format` to get the headers in the right order for
the new location, which has changed the order of other headers in two
files.

This patch allows llvm-dwarfutil to utilize accelerator tables

2023-01-16T13:42:30+00:00

generation code from DWARFLinker. It adds command line option:

--build-accelerator [none,DWARF]
                        Build accelerator tables(default: none)
  =none - Do not build accelerators
  =DWARF - Build accelerator tables according to the resulting DWARF version
       DWARFv4: .debug_pubnames and .debug_pubtypes
       DWARFv5: .debug_names

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

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

2022-12-03T06:10:37+00:00

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

Move TargetRegistry.(h|cpp) from Support to MC

2021-10-08T21:51:48+00:00

This moves the registry higher in the LLVM library dependency stack.
Every client of the target registry needs to link against MC anyway to
actually use the target, so we might as well move this out of Support.

This allows us to ensure that Support doesn't have includes from MC/*.

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

[MC] Refactor MCObjectFileInfo initialization and allow targets to create MCObjectFileInfo

2021-05-23T21:15:23+00:00

This makes it possible for targets to define their own MCObjectFileInfo.
This MCObjectFileInfo is then used to determine things like section alignment.

This is a follow up to D101462 and prepares for the RISCV backend defining the
text section alignment depending on the enabled extensions.

Reviewed By: MaskRay

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

[MC] Untangle MCContext and MCObjectFileInfo

2021-05-05T17:03:02+00:00

This untangles the MCContext and the MCObjectFileInfo. There is a circular
dependency between MCContext and MCObjectFileInfo. Currently this dependency
also exists during construction: You can't contruct a MOFI without a MCContext
without constructing the MCContext with a dummy version of that MOFI first.
This removes this dependency during construction. In a perfect world,
MCObjectFileInfo wouldn't depend on MCContext at all, but only be stored in the
MCContext, like other MC information. This is future work.

This also shifts/adds more information to the MCContext making it more
available to the different targets. Namely:

- TargetTriple
- ObjectFileType
- SubtargetInfo

Reviewed By: MaskRay

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

[DebugInfo] Fix methods of AsmPrinter to emit values corresponding to the DWARF format (1/19).

2020-09-15T04:29:48+00:00

These methods are used to emit values which are 32-bit in DWARF32 and
64-bit in DWARF64. The patch fixes them so that they choose the length
automatically, depending on the DWARF format set in the Context.

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