After https://github.com/llvm/llvm-project/pull/164165, we emit warnings
from non-system headers by default.
This change only preserves functionality of `clang-tidy` as it was
before the change.
Flang alias analysis used to find allocation site by pattern matching
allocation ops in mainly FIR dialect. This MR extends the
characterization to instead characterize based on whether the result of
an op has MemAlloc effect.
This should be the peephole's job. Because and sets V flag to 0, this is
why signed comparisons with 0 are okay to replace with tst. Note this is
only for AArch64, because ANDS on ARM leaves the V flag the same.
Fixes: https://github.com/llvm/llvm-project/issues/154387
This hardens the code to check based on WideMember0's operands. This
ensures each call will go through the same check. Should be NFC
currently but needed when generalizing in follow-up patches.
Make the systemSupportsMemoryTagging() function return even on system
that don't support memory tagging. This avoids the need to always check
if memory tagging is supported before calling th function.
Make systemSupportsMemoryTagging() cache the getauxval return value
instead of calling the function every time.
Updated the code that calls systemSupportsMemoryTagging().
This commit introduces `SpecialCaseList::Match`, a small struct to hold
the matched rule and its line number. This simplifies the `match`
methods by allowing them to return a single value instead of using a
callback.
---------
Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>
It is undefined behavior to call a function with a mismatched calling
convention. Rather than crash on this behavior, it should compile.
This LLVM defect was identified via the AMD Fuzzing project.
Preparing to moving most of implementation out of the header file.
* https://github.com/llvm/llvm-project/pull/167280
---------
Co-authored-by: Naveen Seth Hanig <naveen.hanig@outlook.com>
Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>
This isn't reachable today but will come into play once we reorder
passes for #147352 and #147351.
Note that the `CBufferRowIntrin` helper struct is copied from the
`DXILCBufferAccess` pass, but it will be removed from there when we
simplify that pass in #147351
This relands #167348.
The original PR was reverted due to a reported build failure, which was
later diagnosed as a local issue in the developer’s checkout or build
state. See discussion here:
https://github.com/llvm/llvm-project/pull/163659#discussion_r2511546964
No additional changes have been made in this reland.
This reverts commit c0e4bced616cffe01dd6816638355ae14ced528a.
This was causing issues on older python versions. They are fixed in the
reland and have been tested as working.
On AArch64, ADRP and its user instructions (LDR, ADD, etc.), that are
referencing a GOT symbol, when separated into different functions by
machine outliner exposes a correctness issue in the linker ICF. In such
cases, user instructions can end up pointing to a folded section (with
its canonical folded symbol), while ADRP instruction point to a GOT
entry corresponding to the original symbol. This leads to loading from
incorrect memory address after ICF. #129122 explains how this can happen
in detail.
This addresses #131660 which should fix two things:
1. Hide the correctness issue described above in the LLVM linker.
2. Allows optimizations that could relax GOT addressing to PC-relative
addressing.
There is a possible nullptr deref in BuildCXXNestedNameSpecifier when
calling ExtendNestedNameSpecifier or using isa<>. This initially showed
up as a crash in clangd, that didn't manifest in when compiling w/
clang. The reduced test case added in this patch, however does expose
the issue in clang. Testing locally shows that both this test case and
the original clangd issue are fixed by checking the validity of the
pointer before trying to dispatch. Since all code paths require the
pointer to be valid (usually by virtue of a dyn_cast or isa<> check),
there should be no functional difference.
Fixes#166843
Complex part designators do not have their own symbols. A symbol
obtained for the expression `x%re` will be the symbol for `x`, and in
this case x is allowed to be allocatable.
Fixes https://github.com/llvm/llvm-project/issues/166278.
sincospi/sincospif/sincospil does not appear to exist on common
targets. Darwin targets have __sincospi and __sincospif, so define
and use those implementations. I have no idea what version added
those calls, so I'm just guessing it's the same conditions as
__sincos_stret.
Most of this patch is working to preserve codegen when a vector
library is explicitly enabled. This only covers sleef and armpl,
as those are the only cases tested.
The multiple result libcalls have an aberrant process where the
legalizer looks for the scalar type's libcall in RuntimeLibcalls,
and then cross references TargetLibraryInfo to find a matching
vector call. This was unworkable in the sincospi case, since the
common case is there is no scalar call available. To preserve
codegen if the call is available, first try to match a libcall
with the vector type before falling back on the old scalar search.
Eventually all of this logic should be contained in RuntimeLibcalls,
without the link to TargetLibraryInfo. In principle we should perform
the same legalization logic as for an ordinary operation, trying
to find a matching subvector type with a libcall.
Currently we generate these bounds in the MapInfoFinalization.cpp pass
as it seems there's a missing case for character strings/arrays (length
parameter) in the DirectiveCommons bounds generation functionality
OpenMP uses for it's map operations.
This PR tries to add this case to the DirectiveCommons function and
remove the need for the bounds generation in the MapInfoFinalization
pass, so that we are generating the bounds in the same place most other
bounds are generated.
Add libcall entries for sleef and armpl sincospi implementations.
This is the start of adding the vector library functions; eventually
they should all be tracked here.
I'm starting with this case because this is a prerequisite to fix
reporting sincospi calls which do not exist on any common targets
without
regressing vector codegen when these libraries are available.
This adds code that was previously missing from emitAutoVarAlloca to
identify when an aggregate auto var is being emitted with a constant
initializer, and the associated code that is called from emitAutoVarInit
to store the constant. This allows significantly more efficient
initialization.
This was previously committed in
https://github.com/llvm/llvm-project/pull/166850 but that change
contained an unintended modification to an unrelated test.
conversion of bl memmove call to milicode bl .___memmove64[PR] in
64--bit mode is broken , the patch fix the problem.
in the llvm/include/llvm/IR/RuntimeLibcalls.td, we do not need to define
the
`def ___memmove64 : RuntimeLibcallImpl<MEMCPY>` in PPC64AIXCallList
` def ___memmove32 : RuntimeLibcallImpl<MEMCPY>` in PPC32AIXCallList
since there is function
```
/// Return a function impl compatible with RTLIB::MEMCPY, or
/// RTLIB::Unsupported if fully unsupported.
RTLIB::LibcallImpl getMemcpyImpl() const {
RTLIB::LibcallImpl Memcpy = getLibcallImpl(RTLIB::MEMCPY);
if (Memcpy == RTLIB::Unsupported) {
// Fallback to memmove if memcpy isn't available.
return getLibcallImpl(RTLIB::MEMMOVE);
}
return Memcpy;
}
```
HLSL resources should not be externally visible from the module. We made sure of this by marking them `static` as soon as they were declared. However, this prevents us fixing issue #166458 because there is no way to know if a resource has been explicitly marked `static` by the user, and can therefore be assigned to.
This change moves from making all resources `static` to adding Clang internal linkage attribute to all non-static resource declarations as a global scope.
No explicit test added this change. There is a number of existing HLSL codegen tests that already verify that the resource globals are emitted as `internal global`.
