A bare-bones version of LLVM's unique_function: this behaves like a
std::unique_function, except that it supports move only callable types.
This will be used in upcoming improvements to the ORC runtime.
The "extensible_" prefix on these files was inherited from LLVM, where it
distinguished the dynamic RTTI APIs from the LLVM's custom static RTTI APIs.
In the ORC runtime these files will be used to hold all of our RTTI APIs
(the current dynamic ones, and any static ones added in the future), so we
shouldn't use this prefix.
And use it for test cases that became constant-evaluation-suitable due
to P2562R1.
`TEST_STD_AT_LEAST_(20|23)_OR_RUNTIME_EVALUATED` are the precedents.
We can use *Set::insert_range to collapse:
for (auto Elem : Range)
Set.insert(E);
down to:
Set.insert_range(Range);
In some cases, we can further fold that into the set declaration.
DenseSet recently gained a range constructor:
DenseSet<T> Dest(llvm::from_range, Src);
This patch adds the same signature to SmallSetVector for consistency.
- Move LLVMDISubrangeTypeMetadataKind to end of LLVMMetadataKind enum.
Inserting a new enum constant in the middle of the enum breaks the ABI for
that enum. Commit e298fc2 introduced this issue, which was revealed because
the OCaml binding tests failed.
- Bring OCaml bindings up to date with LLVMMetadataKind enum.
Use the preferred "specifier" term for relocation specifier.
"Relocation modifier" suggests adjustments happen during the linker's
relocation step rather than the assembler's expression evaluation.
The term "relocation specifier" is preferred by Arm for :lower16: and
IBM AIX, and I am trying to standardize in MC.
Pull Request: https://github.com/llvm/llvm-project/pull/132565
ExtractElements are no-ops for scalar VPlans. Don't introduce them in
handleUncountableEarlyExit if the plan has only a scalar VF.
This fixes a crash trying to compute the cost of ExtractElement after 26ecf978951b79.
PR: https://github.com/llvm/llvm-project/pull/131604
DenseSet recently gained a range constructor:
DenseSet<T> Dest(llvm::from_range, Src);
This patch adds the same signature to SetVector, SmallPtrSet,
SmallSet, and StringSet for consistency.
This adds the Xqciint system registers from the Xqci-0.7 spec, as well
as two leftover instructions: `qc.c.mret` and `qc.c.mnret`
Co-authored-by: Sudharsan Veeravalli <quic_svs@quicinc.com>
And introduce MCValue::getAddSym & MCValue::getSubSym to simplify code.
We do not utilize the MCSymbol argument of needsRelocateWithSymbol
as it will go away in the future.
It's the decision of backend needsRelocateWithSymbol whether the
STT_SECTION adjustment should be suppressed.
test/MC/AArch64/data-directive-specifier.s demonstrates how to test this
property.
Follow the X86, Mips, and RISCV renaming.
> "Relocation modifier" suggests adjustments happen during the linker's relocation step rather than the assembler's expression evaluation.
> "Relocation specifier" is clear, aligns with Arm and IBM AIX's documentation, and fits the assembler's role seamlessly.
In addition, rename *MCExpr::getKind, which confusingly shadows the base class getKind.
The parseSpecifier name follows Sparc.
This patch uses DenseSet instead of DenseMap. Note that the set of
Registers that map to true without this patch is the same as the set
of Registers that are present in the set with this patch. This patch
is inspired by:
commit d7879e524fbbc4c2790dac62343444191f736f00
Author: Craig Topper <craig.topper@sifive.com>
Date: Wed Mar 19 08:32:09 2025 -0700
FirstSpecialInsts caches the first special instruction for each basic
block. This patch "inlines" fill into getFirstSpecialInstruction, the
sole caller, to eliminate repeated hash lookups.
On those OSes, clang should set the assembler to enable VIS by default.
This is already the case when clang calls an external assembler, so make
sure clang+IAS use the same defaults.
This should fix [issue #125124](https://github.com/llvm/llvm-project/issues/125124).
This is an implementation for [RFC: Supporting Sub-Channel Quantization
in
MLIR](https://discourse.llvm.org/t/rfc-supporting-sub-channel-quantization-in-mlir/82694).
In order to make the review process easier, the PR has been divided into
the following commit labels:
1. **Add implementation for sub-channel type:** Includes the class
design for `UniformQuantizedSubChannelType`, printer/parser and bytecode
read/write support. The existing types (per-tensor and per-axis) are
unaltered.
2. **Add implementation for sub-channel type:** Lowering of
`quant.qcast` and `quant.dcast` operations to Linalg operations.
3. **Adding C/Python Apis:** We first define he C-APIs and build the
Python-APIs on top of those.
4. **Add pass to normalize generic ....:** This pass normalizes
sub-channel quantized types to per-tensor per-axis types, if possible.
A design note:
- **Explicitly storing the `quantized_dimensions`, even when they can be
derived for ranked tensor.**
While it's possible to infer quantized dimensions from the static shape
of the scales (or zero-points) tensor for ranked
data tensors
([ref](https://discourse.llvm.org/t/rfc-supporting-sub-channel-quantization-in-mlir/82694/3)
for background), there are cases where this can lead to ambiguity and
issues with round-tripping.
```
Consider the example: tensor<2x4x!quant.uniform<i8:f32:{0:2, 0:2}, {{s00:z00, s01:z01}}>>
```
The shape of the scales tensor is [1, 2], which might suggest that only
axis 1 is quantized. While this inference is technically correct, as the
block size for axis 0 is a degenerate case (equal to the dimension
size), it can cause problems with round-tripping. Therefore, even for
ranked tensors, we are explicitly storing the quantized dimensions.
Suggestions welcome!
PS: I understand that the upcoming holidays may impact your schedule, so
please take your time with the review. There's no rush.
This pattern shows up often in media libraries. The optimization should only
kick in for O3. Currently only supports a single family of accumulation
instructions, but can easily be expanded to support additional
instructions in the future.
foldAggregateConstructionIntoAggregateReuse iterates over the entries of
SourceAggregates and the order of inserted instructions depends on the
order of the iterator. Using a regular DenseMap can lead to
non-deterministic value naming/numbering.
I don't think it can actually impact the generated binary, but it makes
diffing IR more difficult.
PR: https://github.com/llvm/llvm-project/pull/132564
Instead of executing the whole entry VPIRBB twice, first only execute
the VPExpandSCEVRecipes and replace their uses with the expanded
VPValue, which will be a live-in. This allows removing special logic in
VPExpandSCEVRecipe to support executing twice and allows moving the
ExpandedSCEVs map out of VPTransformState.
It will also allow adding other recipes to the entry VPBB in the future.
