When a VFS overlay YAML file contains malformed content such as tabs,
the YAML parser can produce KeyValueNode entries where `getKey` returns
nullptr. The VFS overlay parser then passes the nullptr to
`parseScalarString`, which then calls dyn_cast.
Switch to `dyn_cast_if_present` for the above callsites and a few more.
Previously, `computeProcResourceMasks()` would print resource masks on
debug mode from multiple call sites, creating noise in the debug output.
This patch aims to fix this and also print more info about the
resources.
It splits to 2 types of debug prints for resources:
1. No simulation - mask only
2. Simulation - mask + other info
For 2, it shares printing on a single place in `ResourceManager`
constructor, that should cover all the other simulation cases
indirectly:
1. `llvm/lib/MCA/HardwareUnits/ResourceManager` - covered
2. `llvm/lib/MCA/InstrBuilder.c` - should be covered indirectly - only
used by `llvm-mca` before simulation that constructs a `ResourceManager`
3. `llvm/tools/llvm-mca/Views/SummaryView.cpp` - after simulation that
constructs a `ResourceManager`
4. `llvm/tools/llvm-mca/Views/BottleneckAnalysis.cpp` - after simulation
that constructs a `ResourceManager`
It also adds `BufferSize` to the output, which should be useful to debug
scheduling model + MCA integration.
For 1, it inlines mask-only printing into 2 other callers:
1. `llvm/include/llvm/MCA/Stages/InstructionTables.h`
2. `llvm/tools/llvm-exegesis/lib/SchedClassResolution.cpp`
as they only use the masks there. I think this is a reasonable
duplication across distinguishably different users/tools.
Now every pair of callers, even across groups (1 and 2), effectively
print in a mutually exclusive way.
The patch adds debug tests for the 3 new callers, in the corresponding
root test directories, to drive further location of logically
target-independent tests that just require some target at the root. I
think this convention is more discoverable, and is pretty widely used in
the project.
This patch teaches dsymutil to transfer the `__PSEUDO_PROBE` segment and
`__probes` and `__probe_descs` section when creating dSYMs. Without this, both probe sections will get an invalid offset in the dsym bundle.
Make sure that the module has a target triple set before trying to parse
machine functions. This can be required for (downstream) targets if MIR
parsing relies on features guarded by the target triple.
Use CMake's native MACHO_COMPATIBILITY_VERSION and MACHO_CURRENT_VERSION
properties rather than manually pass linker flags. These properties are
available since CMake 3.17.0, released in 2020.
Moving these into the middle-end pipeline will allow for additional
optimization of the expansion result, such as CSE of redundant loads
(c.f. https://godbolt.org/z/bEna4Md9r). For now, we conservatively place
the passes at the end of the middle-end pipeline, so we mostly don't
benefit from additional optimizations yet. The pipeline position will be
moved in a future change.
This builds on work done by legrosbuffle in
https://reviews.llvm.org/D60318.
---------
Co-authored-by: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
This PR extracts the non-visitor methods of class InstExecutor into a
separate class ExecutorAPI. This reorganization allows library functions
(and any future extensions) to reuse the functionality of InstExecutor
without introducing cyclic dependencies.
See also #185645 and #185817.
In LTO, part of LLVM's middle-end runs after linking has finished. LTO's
semantics depend on the complete set of extracted bitcode files being
known at this time. If the middle-end inserts new calls to library
functions (libfuncs) that are implemented in bitcode, this could extract
new bitcode object files into the link. These cannot be compiled,
leading to undefined symbol references.
Additionally, the middle-end in LTO may reason that such library
functions have no references, and it may internalize them, then
manipulate their API or even delete them. Afterwards, it may emit a call
to them, again producing undefined symbol references.
This patch resolves the former issue by ensuring that the middle end
emits no new references to symbols defined in bitcode, and it resolves
the latter issue by ensuring that extracted bitcode for libfuncs is
considered external, since new calls may be emitted to them at any time.
The new semantics are not yet established for MachO LLD, which does not
yet appear to have any special handling for libcalls in LTO. It also
does not yet support distributed ThinLTO; doing so would require
additional (de)serialization work.
This is the patch referenced in @ilovepi's and my talk at the last LLVM
devmeeting: "LT-Uh-Oh"
Gemini 3.1 was used in porting to COFF and WASM LLDs.
Remove four global variables that are set but never read to fix
-Wunused-but-set-global warnings:
- `MFMAChainLength` in AMDGPUIGroupLP.cpp
- `Wide` in llvm-objdump.cpp
- `SaveTemps` in ClangSYCLLinker.cpp
- `DeprecatedDriverCommand` in ClangScanDeps.cpp
Follow up to #178342
This removes dyn_cast invocations where the argument is already of the
target type (including through subtyping). This was created by adding a
static assert in dyn_cast and letting an LLM iterate until the code base
compiled. I then went through each example and cleaned it up. This does
not commit the static assert in dyn_cast, because it would prevent a lot
of uses in templated code. To prevent backsliding we should instead add
an LLVM aware version of
https://clang.llvm.org/extra/clang-tidy/checks/readability/redundant-casting.html
(or expand the existing one).
The in-process ThinLTO backend typically generates object files in
memory and adds them directly to the link, except when the ThinLTO cache
is in use. DTLTO is unusual in that it adds files to the link from disk
in all cases.
When the ThinLTO cache is not in use, ThinLTO adds files via an
`AddStreamFn` callback provided by the linker, which ultimately appends
to a `SmallVector` in LLD. When the cache is in use, the linker supplies
an `AddBufferFn` callback that adds files more efficiently (by moving
`MemoryBuffer` ownership).
This patch adds a mandatory `AddBufferFn` to the DTLTO ThinLTO backend.
The backend uses this to add files to the link more efficiently.
Additionally:
- Move AddStream from CGThinBackend to InProcessThinBackend, for reader
clarity.
- Modify linker comments that implied the AddBuffer path is
cache-specific.
For a Clang link (Debug build with sanitizers and instrumentation) using
an optimized toolchain (PGO non-LTO, llvmorg-22.1.0), measuring the mean
`Add DTLTO files to the link` time trace scope duration:
- On Windows (Windows 11 Pro Build 26200, AMD Family 25 @ ~4.5 GHz, 16
cores/32 threads, 64 GB RAM), this patch reduces the mean from
2799.148 ms to 157.972 ms.
- On Linux (Ubuntu 24.04.3 LTS Kernel 6.14, Ryzen 9 5950X, 16
cores/32 threads, boost up to 5.09 GHz, 64 GB RAM), this patch reduces
the mean from 255.291 ms to 41.630 ms.
Based on work by @romanova-ekaterina and @kbelochapka.
This reverts commit 11b439c5c5a07c95d30ce25abd6adf7f5fbb7105.
timeTraceProfilerCleanup() can be called before the temporary file
deletion has completed in LLD. This causes memory leaks that were
flagged up by sanitizer builds, e.g.:
https://lab.llvm.org/buildbot/#/builders/24/builds/18840/steps/11/logs/stdio
This removes an unnecessary coupling between ExecutorProcessControl and
DylibManager, allowing clients to select DylibManager implementations
independently.
To simplify the transition, the
ExecutorProcessControl::createDefaultJITDylib method will return an
instance of whatever DylibManager the ExecutorProcessControl
implementation had been using previously.
The local `makeStringError` helper in `llvm-symbolizer.cpp` is
equivalent to `createStringError` from `llvm/Support/Error.h`. Remove it
and use `createStringError` directly at all call sites.
Add the -remove flag to llvm-lipo. This matches the existing Darwin lipo
tool:
```
% xcrun lipo 2>&1 | grep remove
error: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/lipo: one of -create, -thin <arch_type>, -extract <arch_type>, -remove <arch_type>, -replace <arch_type> <file_name>, -verify_arch <arch_type> ... , -archs, -info, or -detailed_info must be specified
-remove <arch_type> [-remove <arch_type> ...]
```
Assisted-by: claude-code
Previously, a command like `llc -mcpu=help` would fail on invalid target
triple, due to wrongly passing empty target to `Triple::normalize`
resulting in `unknown`.
This patch enables `-mcpu=help` or `-mattr=help` invocation without an
input file, like `llc`. For example, the following command `opt
-mtriple=aarch64 -mattr=help` would previously hang but now it succeeds.
The implementation is similar to llc, creating a target machine for help
printing side effects and existing early. Note: llc has a bug in the
default triple handling that we already fix here upfront. Ill submit a
separate fix for llc.
The sancov tool fails to find coverage symbols in XCOFF object files
because XCOFF uses a "." prefix for function entry point symbols. For
example, `__sanitizer_cov_trace_pc_guard appears` as
`.__sanitizer_cov_trace_pc_guard` in the symbol table.
Before this change, sancov reports:
`ERROR: __sanitizer_cov* functions not found`
This change strips the prefix "." when checking symbol names in XCOFF
files, allowing sancov to correctly identify coverage symbols.
---------
Co-authored-by: Honey Goyal <honey.goyal3@ibm.com>
AsmPrinter (clang -c a.c) and AsmParser (clang -c a.s, llvm-mc
-filetype=obj a.s) have different ways to emit .note.GNU-stack section.
913c5b4d1fff removed a redundant initSections call from cc1as, but
that was the only place where NoExecStack was consumed for the
assembler path.
Unify the .note.GNU-stack emission in MCELFStreamer::finishImpl,
making the `initSections` parameter redundant.
Add a -filetype=obj test for Solaris (see
https://reviews.llvm.org/D159179), which doesn't use .note.GNU-stack
`initSections` has 20+ uses. The parameter cleanup will be deferred to a
subsequent change.
Fixes https://github.com/llvm/llvm-project/issues/186004
The TPI and IPI streams didn't include a hash map for the generated
types, because the types never got hashes. A hash map is necessary to
resolve forward references when dumping the PDB (checks for
`TpiStream::supportsTypeLookup` which checks the hash map).
With this PR, the hashes are generated. There's no good test that we do
this for the IPI stream as well, because it doesn't have forward
references.
Assembly files compiled with debug info generate `DW_TAG_label entries`
with `DW_AT_low_pc` but no `DW_AT_high_pc` attributes. Without address
range information, `dsymutil` would call `addLabelLowPc()` which only
records the start address, making the compilation unit appear "empty"
with no ranges. This caused dsymutil to discard all debug information
including line tables.
This patch adds infrastructure to query symbol sizes from the debug map
and use them to reconstruct address ranges for assembly labels.
rdar://166225328
---------
Co-authored-by: Ryan Mansfield <ryan_mansfield@apple.com>
- Invert the condition to make the code more straight and sink
single-use variables there.
- Add a comment about on `createTargetMachine` side effects for
`-mcpu=help`.
- Remove redundant call to `setPGOOptions`
This patch adds a Clang-compatible -mtune option to llc, to enable
decoupled ISA and microarchitecture targeting, which is especially
important for backend development. For example, it can enable to easily
test a subtarget feature or scheduling model effects on codegen across a
variaty of workloads on the IR corpus benchmark:
https://github.com/dtcxzyw/llvm-codegen-benchmark.
The implementation adds an isolated generic codegen flag, to establish a
base for wider usage - the plan is to add it to `opt` as well in a
followup patch. Then `llc` consumes it, and sets `tune-cpu` attributes
for functions, which are further consumed by the backend.
Deleting the temporary files produced by the DTLTO ThinLTO backend can
be expensive on Windows hosts. For a Clang link (Debug build with
sanitizers and instrumentation) using an optimized toolchain (PGO
non-LTO, llvmorg-22.1.0) on a Windows 11 Pro (Build 26200), AMD Family
25 @ ~4.5 GHz, 16 cores / 32 threads, 64 GB RAM machine, the mean
duration of the "Remove DTLTO temporary files" time trace scope was
1267.789 ms (measured over 10 runs).
This patch performs the deletions on a background thread, allowing them
to overlap with the remainder of the link to hide this cost.
Based on work by @romanova-ekaterina and @kbelochapka.
This adds support for `S_DEFRANGE_REGISTER_REL_INDIR` (as
`DefRangeRegisterRelIndirSym`).
It's to `S_REGREL32_INDIR` what `S_DEFRANGE_REGISTER_REL` is to
`S_REGREL32`. `S_REGREL32_INDIR` was added in #183172.
LLVM only generates `S_LOCAL` for variables and parameters, so we need
this record to specify a range where a variable is indirectly accessed.
I didn't find any PDB where this record is in, so I guessed the layout
based on `S_DEFRANGE_REGISTER_REL` and `S_REGREL32_INDIR`. Locally, I
updated LLVM to generate this where possible, and tested it with the VS
debugger and WinDBG. Both handled the record correctly. This PR doesn't
include the change to debug info generation yet - you can find the
current WIP in
884072fa17.
The name `OffsetInUdt` comes from DIA
([`get_offsetInUdt`](https://learn.microsoft.com/en-us/visualstudio/debugger/debug-interface-access/idiasymbol-get-offsetinudt?view=visualstudio)).
Given that this symbol also has a `offsetInParent`, I find the name a
bit confusing. When generating the record in the commit above, I used
the name `DerefOffset`. If we change it here, it should be changed in
`RegRelativeIndirSym` as well.
Previously a command like `llc -mtriple=aarch64 -mattr=+zcm-fpr64
-mattr=help` would hang, instead of printing help text and exiting. This
patch provides a fix by relaxing the previous constraint where
`-mattr=help` must have been first among attrs. It can now appear
anywhere.
Includes a test to cover both `-mcpu=help` and `-mattr=help` for llc.
Add `--sort` to emit remarks in sorted order and `--dedupe` to
deduplicate identical remarks. Only if these options are requested,
remarks need to be buffered into a sorted map before emission.
Pull Request: https://github.com/llvm/llvm-project/pull/187338
Adds a port for AArch64ExpandPseudo to NewPM.
- Refactored lib/Target/AArch64/AArch64ExpandPseudoInsts.cpp to extract
base logic as Impl
- Renamed existing pass with "Legacy" suffix and updated references
- Added NewPM pass AArch64ExpandPseudoPass
- Updated tests
Following tests mention this pass but weren't migrated because they need
a full codegen pipeline which doesn't exist yet.
```
LLVM :: CodeGen/AArch64/GlobalISel/arm64-pcsections.ll
LLVM :: CodeGen/AArch64/addg_subg.mir
LLVM :: CodeGen/AArch64/rvmarker-pseudo-expansion-and-outlining.mir
LLVM :: CodeGen/AArch64/spillfill-sve.mir
LLVM :: CodeGen/AArch64/subreg_to_reg_coalescing_issue.mir
```
Refactor filter into a FilterTool class that can process multiple input
files sequentially and emits the remarks into a single output file.
Pull Request: https://github.com/llvm/llvm-project/pull/187162
The function instructionsWithoutDebug serves two uses: skipping debug
intrinsics and skipping pseudo instructions. Nonetheless, these
functions are expensive due to out-of-line filtering using
std::function. Ideally, the filter should be inlined, but that would
require including IntrinsicInst.h in BasicBlock.h.
We no longer use debug intrinsics, so the first use (parameter false) is
no longer needed. The second use is sometimes needed, but the
distinction between PseudoProbe instructions can be made at the call
sites more easily in many cases.
Therefore, remove instructionsWithoutDebug/sizeWithoutDebug.
c-t-t stage2-O3 -0.21%.
While the functionality of this flag is obvious in the implementation,
tool users may not know what it does with the short description
provided. Notably, it is not obvious from the short description that:
* Functions provided will be converted to internal linkage (and thus
discarded if unused) even if unreferenced.
* Functions in the first file will not be internalized, even if
referenced by a later one.
The Rust for Linux project has [found use for this
flag](https://lore.kernel.org/all/20251202-inline-helpers-v1-0-879dae33a66a@google.com/)
to support inlining `static inline` functions in C into code compiled by
Rust when `rustc` and `clang` share a LLVM.
This patch relands https://github.com/llvm/llvm-project/pull/178666. The
original version caused CI failures due to the missing target triple in
`llvm/test/CodeGen/X86/byte-constants.ll`. CI should be green now.
Summary:
The return value was not zeroed, this was accidentally dropped when we
did the port and it's zero "almost always" so I didn't notice. Hopefully
this makes the test suite no longer flaky.
Previously, llvm-mc always defaulted to output assembly variant 0
regardless of the target's AssemblerDialect. This was inconsistent:
llvm-mc -x86-asm-syntax=intel changed the input parser to Intel syntax
but output stayed AT&T, unlike clang's -masm=intel which affects both.
When --output-asm-variant is not explicitly specified, fall back to
MAI->getAssemblerDialect() instead of hardcoding variant 0. This
makes the output match the target's configured dialect:
- X86: -x86-asm-syntax=intel now produces Intel output
- AArch64: Apple triples default to Apple syntax output
- SystemZ: z/OS triples default to HLASM syntax output
Tests that relied on a specific output variant now use explicit
--output-asm-variant=0.
Relocate HTTPClient and HTTPServer from the Debuginfod library to
llvm/Support/HTTP so they can be reused by other components.
---------
Relanding with fixes in CMakeLists.txt to account for dependency to new LLVMSupportHTTP in tools.
Relanding with one more fix in libSupportHTTP that adds it as a component in libLLVM.so
---------
Co-authored-by: Alexandre Ganea <aganea@havenstudios.com>
Co-authored-by: Jonas Devlieghere <jonas@devlieghere.com>
