Try to reduce individual subtarget features in the "target-features"
attribute. This attempts a textual removal of the fields in the string,
not a semantic removal. Typically there's a lot of redundant feature spam
in the feature list implied by the target-cpu (which I really wish clang
would stop emitting). If we could parse these out, we could easily drop
the fields without testing anything.
We can use *Set::insert_range to collapse:
for (auto Elem : Range)
Set.insert(E.first);
down to:
Set.insert_range(llvm::make_first_range(Range));
In some cases, we can further fold that into the set declaration.
I'm looking into using sub-operands for memory operands. This would use
MIOperandInfo to create a single operand that contains a register and
immediate as sub-operands. We can treat this as a single operand for
parsing and matching in the assembler. I believe this will provide some
simplifications like removing the InstAliases we need to support "(rs1)"
without an immediate.
Doing this requires making CompressInstEmitter aware of sub-operands.
I've chosen to use a flat list of operands in the CompressPats so each
sub-operand is represented individually.
SubToSuperRegs was a DenseMap of std::vectors, where the vectors
typically had size 1. Switching to a vector of pairs avoids the overhead
of allocating tiny vectors.
I measured a 1.14x speed-up building AMDGPUGenRegisterInfo.inc with this
patch.
Introduced a cmake option that is disabled by default that suppresses
searching via the PATH variable for a symbolizer. The option will be
enabled for downstream builds where the user will need to specify the
symbolizer path more explicitly, e.g., by using ASAN_SYMBOLIZER_PATH.
Previously isAlocatable was updated to allow inheritance from any
superclass for a generated register class, but other properties are
still inherited from its nearest superclass. This could cause
a generated regclass inherit undesired properties, e.g., tsflags, from
an unallocatable superclass due to the topological inheritance order.
This change updates to inherit properties from the nearest allocatable
superclass if possible and includes a test to demonstrate a potential
incorrect inheritance of tsflags.
I was looking at the value range of AcquireAtCycle / ReleaseAtCycle, and
I noticed that while the TableGen error messages said AcquireAtCycle has
to be less than ReleaseAtCycle, in reality they are actually allowed to
be the same. This patch fixes it and add more test cases.
When a developer copy/pastes a failing command line into their
shell to rerun it, they have to manually delete the "RUN: at line
N:" prefix. To make life easier for such developers, let's make it
possible to copy/paste a command without needing to modify it while
still showing the line number in the output by moving the line number
to a comment at the end of the command line.
Reviewers: jroelofs, MaskRay
Reviewed By: jroelofs, MaskRay
Pull Request: https://github.com/llvm/llvm-project/pull/132485
In the CMake build the default pstl backend for libc++ when threads are
enabled is std_thread. By selecting the wrong backend we were triggering
some transitive_includes test failures.
Reviewers: aeubanks, nico
Reviewed By: aeubanks
Pull Request: https://github.com/llvm/llvm-project/pull/132455
DenseSet, SmallPtrSet, SmallSet, SetVector, and StringSet recently
gained C++23-style insert_range. This patch replaces:
Dest.insert(Src.begin(), Src.end());
with:
Dest.insert_range(Src);
This patch does not touch custom begin like succ_begin for now.
- Remove definitions from DXIL.td and any emissions/definitions that
were previously planned to be used
See resolved issue for motivations of deletion
Resolves#126298
The CMake side always defines _LIBCPP_ABI_VERSION. If we do not, we will
at least get -Wundef warnings in the test suite (upgraded to errors)
and it looks like we will end up building the library incorrectly as well.
With that, most of the libc++ test suite passes (with a manually written
lit.site.cfg) aside from some parts related to C++ modules which we
don't support yet.
Reviewers: nico, aeubanks
Reviewed By: aeubanks
Pull Request: https://github.com/llvm/llvm-project/pull/132135
Most places that call Intrinsic::getAttributes() are only interested in
the function attributes, so add a separate function for that.
The motivation for this is that I'd like to add the ability to specify
range attributes on intrinsics, which requires knowing the function
type. This avoids needing to know the type for most attribute queries.
The current parsing logic for the target string assumes it follows the
format `<kind>-<triple>-<target id>:<feature>`, such as
`hipv4-amdgcn-amd-amdhsa-gfx1030:+xnack`.
Specifically, it assumes that `<target id>` does not contain any `-`,
relying on `rsplit` for parsing.
However, this assumption breaks for AMDGPU's generic targets, which may
contain one or more `-`, such as `gfx10-3-generic` or `gfx12-generic`.
As a result, the existing approach using `rstrip` is no longer reliable.
This patch reworks the parsing logic to handle target strings more
robustly, including support for generic targets.
The bundler now strictly requires a 4-field target triple.
Additionally, a new Python helper function has been added to `config.py`
to normalize the target triple into the 4-field format when it is not,
ensuring tests pass reliably.
Whilst trying to clean up some loop vectoriser IR tests (see
test/Transforms/LoopVectorize/AArch64/partial-reduce-chained.ll
for example) a reviewer on PR #129047 suggested it would be
nice to have an option to stop generating CHECK lines after a
certain point. Typically when performing a transformation with
the loop vectoriser we don't usually care about any CHECK lines
generated for the scalar tail of the loop, since the scalar
loop is kept intact. Previously if you wanted to eliminate such
unwanted CHECK lines you had to run the update script, then
manually delete all the lines corresponding to the scalar loop.
This can be very time consuming if the tests ever need changing.
What I've tried to do here is add a new --filter-out-after
option alongside the existing --filter* options that provides
support for stopping the generation of any CHECK lines beyond
the line that matches the filter. With the existing filter
options we never generate CHECK-NEXT lines, but we still care
about ordering with --filter-out-after so I've amended the
code to ensure we treat this filter differently.
