When an indirect branch instruction is decoded, analyzeIndirectBranch
method is asked if this is a well-known code pattern. On AArch64, the
only special pattern which is detected is Jump Table, emitted as a
branch to the sum of a constant base address and a variable offset.
Therefore, `Inst.getOpcode()` being one of `AArch64::BRA*` means Inst
cannot belong to such Jump Table pattern, thus returning early.
andorbitset.ll is interesting since it directly depends on the
difference between poison and undef. Not sure it's useful to keep
the version using poison, I assume none of this code makes it to
codegen.
si-spill-cf.ll was also a nasty case, which I doubt has been reproducing
its original issue for a very long time. I had to reclaim an older version,
replace some of the poison uses, and run simplify-cfg. There's a very
slight change in the final CFG with this, but final the output is approximately
the same as it used to be.
Since a68d20e98, we've been calling HandleDelayedAccessCheck() for
concept declarations when the declaration contains invalid member
accesses.
However, a concept declaration is TemplateDecl such that doesn't contain
any TemplatedDecl.
Fixes https://github.com/llvm/llvm-project/issues/131530
So far CSA was relying on the LLVM Statistic package that allowed us to
gather some data about analysis of an entire translation unit. However,
the translation unit consists of a collection of loosely related entry
points. Aggregating data across multiple such entry points is often
counter productive.
This change introduces a new lightweight always-on facility to collect
Boolean or numerical statistics for each entry point and dump them in a
CSV format. Such format makes it easy to aggregate data across multiple
translation units and analyze it with common data-processing tools.
We break down the existing statistics that were collected on the per-TU
basis into values per entry point.
Additionally, we enable the statistics unconditionally (STATISTIC ->
ALWAYS_ENABLED_STATISTIC) to facilitate their use (you can gather the
data with a simple run-time flag rather than having to recompile the
analyzer). These statistics are very light and add virtually no
overhead.
Co-authored-by: Balazs Benics <benicsbalazs@gmail.com>
CPP-6160
Finds lambda captures that capture the ``this`` pointer and store it as
class
members without handle the copy and move constructors and the
assignments.
Capture this in a lambda and store it as a class member is dangerous
because the
lambda can outlive the object it captures. Especially when the object is
copied
or moved, the captured ``this`` pointer will be implicitly propagated to
the
new object. Most of the time, people will believe that the captured
``this``
pointer points to the new object, which will lead to bugs.
Fixes: #120863
---------
Co-authored-by: Baranov Victor <70346889+vbvictor@users.noreply.github.com>
Co-authored-by: Baranov Victor <bar.victor.2002@gmail.com>
Below semantic checks for Taskloop clause mentioned in OpenMP [5.2]
specification were missing, this patch contains the semantic checks,
corresponding error messages and test cases:
OpenMP standard [5.2]:
[12.6] Taskloop Construct
[Restrictions]
Restrictions to the taskloop construct are as follows:
• The reduction-modifier must be default.
• The conditional lastprivate-modifier must not be specified.
Authored-by: shkaushi <sharang.kaushik@amd.com>
Code complete `constexpr` and `consteval` keywords after `if` in the
relevant language modes. If pattern completion is enabled, the
completions also include placeholders for the condition (in the case
of `constexpr`) and statement block.
This is a code cleanup. Update a few places in MLIR that should use
`hasSingleElement`/`getSingleElement`.
Note: `hasSingleElement` is faster than `.getSize() == 1` when it is
used with linked lists etc.
Depends on #131508.
The interval of newly generated reg in ModuloScheduleExpander is empty.
This will cause crash at some corner case. This patch recalculate the
live intervals of these regs.
Target shouldForceRelocation checks `FirstLiteralRelocationKind` to
determine whether a relocation is forced due to the .reloc directive. We
should move the code to evaluateFixup so that many targets don't need to
override shouldForceRelocation.
When pragma of loop transformations are encoded in LLVM IR, follow-up
metadata is used if multiple transformations are specified. They are
used to explicitly express the order of the transformations. However,
they are not properly processed on each transformation pass, so now only
the first one is attempted to be applied. This is a pre-commit to add a
test that causes the problem.
ref:
https://github.com/llvm/llvm-project/pull/127474#issuecomment-2717790398
When a function pointer is annotated with
`void (*fptr)(void) __attribute__((nocf_check));`, calling it should use
the NOTRACK prefix, as the callee may not contain an ENDBR.
https://reviews.llvm.org/D41879 implemented NOTRACK variants for
X86ISD::CALL and ISD::BRIND but not for TCRETURN. Given that there are
so many tail call variants (e.g. conditional tailcall
https://reviews.llvm.org/D29856), let's just disable tailcall.
While nocf_check has some uses within the Linux kernel, it isn't a
popular attribute.
Fix#91228
Pull Request: https://github.com/llvm/llvm-project/pull/131487
This commit adds a new helper function: `getSingleElement`
This function asserts that the container has a single element and then
returns that element. This helper function is useful during 1:N dialect
conversions in MLIR, where certain `ValueRange`s (returned from the
adaptor) are known to have a single value.
Make test target-dependent, as they will require access to a concrete
vector register width. Also add new tests for cost modeling, unrolling
and removing the vector loop region.
