Summary:
I made the GPU flags accept more of the default LLVM warnings, which
triggered some new cases. Clean those up and fix some other ones while
I'm at it.
With declare mapper, the parent base entry was emitted as `TARGET_PARAM`
only. The mapper received a map-type without `to/from`, causing
components to degrade to `alloc`-only (no copies), breaking allocatable
payload mapping. This PR preserves the map-type bits from the parent.
This fixes#156466.
This patch makes the following updates to the `QualGroup.rst`
documentation:
✅ 1. Replace slide links with Google Drive URLs
Replaced links to slide PDFs previously hosted in `llvm/docs/qual-wg/`
with publicly accessible links to the same files stored on Google Drive.
✅ 2. Remove duplicated "Current Topics & Backlog" section
Removed an accidental duplication of the "Current Topics & Backlog"
section to improve clarity and structure.
✅ 3. Add "AI Transcription Policy" section
Introduced a dedicated section documenting the group's practices and
expectations regarding AI-based auto-transcription during sync-up
meetings. Includes purpose, consent practices, retention details, and
how participants can opt out or raise concerns.
✅ 4. Remove `qual-wg` subfolder from `docs`
Removed the now-unused `llvm/docs/qual-wg` directory after migrating
slide hosting off-repo. No longer needed for qualification group
documentation.
✅ 5. Revision of the introduction
Updated sentence to reflect the most current and widely relevant safety
standards: adding IEC 61508 and IEC 62304 for broader applicability, and
replacing EN 50128 (older standard in railways) by EN 50716 for
correctness.
---------
Co-authored-by: Wendi Urribarri (Woven by Toyota <wendi.urribarri@woven-planet.global>
When handling CUDA ELF files via objdump or LLDB, the ELF parser in LLVM
needs to distinguish if an ELF file is sass or not, which requires a
triple for sass to exist in llvm. This patch includes all the necessary
changes for LLDB and objdump to correctly identify these files with the
correct triple.
This makes the UEFI driver's handling of linking more canonical
in a few ways:
* Use /option:value syntax with lld-link as in the MSVC driver.
* Handle -nostdlib, -nodefaultlibs, -r and call common
subroutines when they aren't set. This covers sanitizer and
profile runtimes and their associated switches; compiler-rt
builds do not yet provide these libraries, but the driver
behavior is opt-in and supports all the opt-in/out plumbing
like other targets do. This lets command lines immediately
use the opt-out switches even when they are superfluous for
opt-in features, as build system plumbing often needs to do.
It also updates some TODO comments for how the driver behavior
will look when more runtime support is ready.
Remove 'lldb-python-scripts' from LLVM_DISTRIBUTION_COMPONENTS when
Python scripting is disabled. Otherwise we get
```
Specified distribution component 'lldb-python-scripts' doesn't have an install target
```
Summary:
The AMDGPU hack can be removed, and we no longer need to skip 90% of the
`HandleLLVMOptions` if we work around NVPTX earlier. Simplifies the
interface by removing duplicated logic and keeps the GPU targets from
being weirdly divergent on some flags.
Right now, cross-building `lldb` means either installing a native
`lldb-tblgen` by hand (non-trivial, as CMake is painful) or first
building all of native clang because of how the CMake rules work, which
is not fun.
In keeping with the pattern established by llvm-tblgen and clang-tblgen,
install lldb-tblgen to ease cross-compilation.
Co-authored-by: Ross Burton <ross.burton@arm.com>
This change adds basic `MCInst` verification (checks the number of
operands) and fixes detected bugs.
* `RFE*` instructions have only one operand, but `DecodeRFEInstruction`
added two.
* `DecodeMVEModImmInstruction` and `DecodeMVEVCMP` added a `vpred`
operand, but this is what `AddThumbPredicate` normally does. This
resulted in an extra `vpred` operand.
* `DecodeMVEVADCInstruction` added an extra immediate operand.
* `getARMInstruction` added a `pred` operand to instructions that don't
have one (via `DecodePredicateOperand`).
* `AddThumb1SBit` appended an extra register operand to instructions
that don't modify CPSR (such as `tBL`).
* Instructions in `NEONDup` namespace have `pred` operand that the
generated code successfully decodes. The operand was added once again by
`getARMInstruction`/`getThumbInstruction` via `AddThumbPredicate`.
Functional changes extracted from #156540.
This PR adds the features needed for supporting the GEMM with transpose
B case.
Summary of changes.
1). Add distribution logic for `vector.bitcast`, `vector.transpose` and
`memref.extract_aligned_pointer_as_index` cases.
2). Add layout propagation support for `vector.shape_cast`,
`vector.broadcast` and `vector.bitcast`
3). Incorporate slice attribute and `DistributeLayoutAttr` interface
with the core logic in layout prop.
This is a very rough state of what this can look like, but I didn't want
to spend too much time on what could be a dead end.
Currently the only way to invoke callbacks is by using the default
pipelines, this is an issue if you want to define your own pipeline
using the C string API (we do that in LLVM.jl in julia) so I extended
the api to allow for invoking those callbacks just like one would call a
pass of that kind.
There are some questions about the params that these callbacks take and
also I'm missing some of them (some of them are also invoked by the
backend so we may not want to expose them)
Code written with AI help, bugs are mine. (Not sure what policy for this
is on LLVM)
Summary:
This exposes the 'isDeviceCompatible' routine for checking if a binary
*can* be loaded. This is useful if people don't want to consume errors
everywhere when figuring out which image to put to what device.
I don't know if this is a good name, I was thining like `olIsCompatible`
or whatever. Let me know what you think.
Long term I'd like to be able to do something similar to what OpenMP
does where we can conditionally only initialize devices if we need them.
That's going to be support needed if we want this to be more
generic.
Add `bits<0>` fields to instructions using the ZTR/MPR/MPR8 register
classes. These register classes contain only one register, and it is
not encoded in the instruction. This way, the generated decoder can
completely decode instructions without having to perform a post-decoding
pass to insert missing operands.
Some immediate operands are also not encoded and have only one possible
value "zero". Use this trick for them, too.
Finally, remove `-ignore-non-decodable-operands` option from
`llvm-tblgen` invocation to ensure that non-decodable operands do not
appear in the future.
Rather then defining these tags in each object file that requires them
we can can declare them as undefined and require that they defined
externally in, for example, compiler-rt or libcxxabi.
Add `--print-gc-sections=<file>` to redirect garbage collection section
listing to a file, avoiding contamination of stdout with other linker
output. mold has recently added the option.
GNU ld feature request:
https://sourceware.org/bugzilla/show_bug.cgi?id=33331
These instructions have one already narrow operand. Previously, we
pretended like this operand was a supported extension.
This could cause problems when we called getOrCreateExtendedOp on this
narrow operand when creating the the VWADD_VL. If the narrow operand
happened to be an extend of the opposite type, we would peek through it
and then rebuild it with the wrong extension type. So (vwadd_w_vl (i32
(sext X)), (i16 (zext Y))) would become (vwadd_vl (i16 (sext X)), (i16
(sext Y))).
To prevent this, we ignore the operand instead and pass std::nullopt for
SupportsExt to getOrCreateExtendedOp so it won't peek through any
extends on the narrow source.
Fixes#159152.
This PR uses the same trick as 7ced9fff95473 to ensure the
`g_core_definitions` table is correctly indexed by the Core enum. It's
easy to make a mistake. Case in point: this caught two entries that
appeared in the wrong order.
Teach the IR parser and writer to support metadata on ifuncs, and update
documentation.
In PR #153049, we have a use case of attaching the `!associated`
metadata to an ifunc.
Since an ifunc is similar to a function declaration, it seems natural to
allow metadata on ifuncs.
Currently, the metadata API allows adding Metadata to
llvm::GlobalObject, so the in-memory IR allows for metadata on ifuncs,
but the IR reader/writer is not aware of that.
---------
Co-authored-by: Wael Yehia <wyehia@ca.ibm.com>
This patch adds a new %{readfile:<file name>} substitution to lit. This
is needed for porting a couple of tests to lit's internal shell. These
tests are all using subshells to pass some option to a command are not
feasible to run within the internal shell without this functionality.
Reviewers: petrhosek, jh7370, ilovepi, cmtice
Reviewed By: jh7370, cmtice
Pull Request: https://github.com/llvm/llvm-project/pull/158441
The GNU Fortran library function FNUM(u) returns the UNIX file
descriptor that corresponds to an open Fortran unit number, if any;
otherwise -1.
This implementation is a library extension only, not an intrinsic.
First added in #153585 for Darwin only. All Linux AArch64 systems also
have Top Byte Ignore enabled in userspace so the test "just works"
there.
FreeBSD has very recently gained Top Byte Ignore support:
4c6c27d3fb
However it's so recent, I don't want to assume it'll be available on any
random FreeBSD system out there.
There isn't really a good place to put this test, so I put it in the top
level of API, next to the other non-address bit test that didn't have a
good home either.
When build with assertions, there will be an output like the following
that needs to be filtered out, similar to the other ones.
`'Build config: +assertions'`
The atomic_wait benchmarks are great, but they tend to overload the
system they're running on. For that reason, we can't run them on our CI
infrastructure on a regular basis.
Instead of removing them, make them unsupported outside of dry-running,
which allows keeping the benchmarks around and ensuring they don't rot,
but doesn't run them along with the other benchmarks. If we need to
investigate atomic_wait performance, it's trivial to mark the benchmark
as supported and run it for local investigations.
This is an alternative to https://github.com/llvm/llvm-project/pull/158289.
This should eventually be done using `lnt` instead, but for the time
being this makes it easy to visualize historical data without having
an instance of `lnt` running.
