The resource attribute was added, but the code to be able to parse it
as we do with other resource attributes was missing. This means we are
not able to test the attribute in isolation.
This change adds the parsing for the attribute, and adds more testing
for it.
Assisted-by: Gemini
<!-- branch-stack-start -->
-------------------------
- main
- https://github.com/llvm/llvm-project/pull/185039👈
<sup>[Stack](https://www.git-town.com/how-to/proposal-breadcrumb.html)
generated by [Git Town](https://github.com/git-town/git-town)</sup>
<!-- branch-stack-end -->
replace `cast<VarDecl>` with `dyn_cast_or_null<VarDecl>` in
`HandleImmediateInvocations` to avoid the crash when
`ManglingContextDecl` is a `FunctionDecl` instead of a `VarDecl`.
fixes#185270
Allows us to get useful recordings out of JIT sessions that crash, or are kept
alive indefinitely. (Note that an 'end' operation will have to be appended to
the output in these cases).
This check's bespoke method of avoiding matching
in template instantations is overeager. This commit
changes it to just rely on IgnoreUnlessSpelledInSource
traversal instead. This is the same problem
as in #185559.
The verifier of the TileOp did not allow composition of multiple
transformations out of precaution. However, composition works, therefore
remove the "currently only supports omp.canonical_loop as applyee" check
and add regression tests.
Implement the remaining CIR lowerings for the AdvSIMD (Neon)
`vceqz` intrinsic group (bitwise equal to zero).
Most variants of `vceqz` variant were already supported; this patch
completes the rest of the group [1] that was left as a TODO.
Tests for these intrinsics are moved from:
* test/CodeGen/AArch64/neon_intrinsics.c
* test/CodeGen/AArch64/v8.2a-fp16-intrinsics.c
to:
* test/CodeGen/AArch64/neon/intrinsics.c
* test/CodeGen/AArch64/neon/fullfp16,
respectively.
The implementation largely mirrors the existing lowering in
CodeGen/TargetBuiltins/ARM.cpp.
Reference:
[1] https://arm-software.github.io/acle/neon_intrinsics/advsimd.html#bitwise-equal-to-zero
When narrowInterleaveGroups transforms a plan, VF and VFxUF are
materialized (replaced with concrete values). This patch also
materializes the VectorTripCount in the same transform.
This ensures that VectorTripCount is properly computed when the narrow
interleave transform is applied, instead of using the original VF
+ UF to compute the vector trip count. The previous behavior generated
correct code, but executed fewer iterations in the vector loop.
The change also enables stricter verification prevent accesses of UF,
VF, VFxUF etc after materialization as follow-up.
Note that in some cases we no miss branch folding, but that should be
addressed separately, https://github.com/llvm/llvm-project/pull/181252
Fixes one of the violations accessing a VectorTripCount after UF and VF
being materialized
PR: https://github.com/llvm/llvm-project/pull/182146
For amdgpu use the exp intrinisc. Really, this should be
the default generic implementation. But we're stuck in a
mess where essentially nothing works. All of the exp
intrinsics work for AMDGPU, but aren't really implemented
for spirv or nvptx. Ideally the intrinsic and/or libm call
would be the default implementation.
Recently, the consistent flag and the peeling flags were removed from
the `Dependence` class (#181608, #183737). However, the related comments
were not deleted accordingly. This patch cleans them up.
Reverts llvm/llvm-project#180751
Enabling this pass by default breaks a few tests / use cases downstream.
@frederik-h was also looking into the actual implementation of the pass.
For now: Just revert that pass to be on-by-default.
Also fix a typo in the process.
---------
Co-authored-by: Jay Foad <jay.foad@amd.com>
The generic intrinsic should be used. A very long time ago
the sqrt intrinsic did not work for f64, but it's implemented
essentially the same way as this.
To address the issue of clang frontend crashes caused by @param
annotations being attached to unavailable nodes, I modified
RawComment::parse, adding a Decl check to prevent illegal data from
entering ParamVars.
Fixed#182737
Not all AArch64 intrinsics categorized as SISD (Single Instruction
Single Data) are truly SISD. Add comments clarifying this distinction.
Also update EmitCommonNeonSISDBuiltinExpr:
* Move the assert to the top of the function and add a descriptive
message to make the assumptions explicit.
* Remove unnecessary temporary variables (e.g. BuiltinID) and use
SISDInfo directly.
No functional changes intended.
Without the overload constrain lowering would go with a default path
which would later result in a crash in case if for example AMDGPU asm is
inlined (for example v_ would be Unknown).
Overload sets ConstraintType to be always RegClass for SPIR-V.
This is diverges from GCC and breaks overload resolution for some SVE
builtins. For example, calling `svsel` is ambiguous on Clang (not GCC):
```c
using fixed_bool = svbool_t __attribute__((arm_sve_vector_bits(128)));
using fixed_u8 = svuint8_t __attribute__((arm_sve_vector_bits(128)));
fixed_u8 test(fixed_bool pred, fixed_u8 a, fixed_u8 b) {
// error: call to 'svsel' is ambiguous
// note: candidate function: svbool_t svsel(svbool_t, svbool_t, svbool_t);
// note: candidate function: svuint8_t svsel(svbool_t, svuint8_t, svuint8_t);
return svsel(pred, a, b);
}
```
See: https://godbolt.org/z/o3r9d5fW4
Previously, USRGeneration was implemented by clangIndex. However, that
poses too broad library layering constraints on the ever growing set of
users of a tiny component of it, USRGeneration.
This PR splits that into a small library, called:
clangUnifiedSymbolResolution
Anyone needing USRGeneration could simply link against this without
pulling in everything from clangIndex.
---
Importantly, clangIndex linked against clangFrontend to define its
FrontendAction, and use some ASTUnit APIs. Some users may want to use
USRGeneration but NOT depend on clangFrontend. This new
clangUnifiedSymbolResolution library would solve such circular
dependencies.
PS: There were quite a few cases where libraries could just link against
clangUnifiedSymbolResolution without linking to clangIndex. I've
simplified those cases in this PR, to keep link deps minimal.
Flang currently lowers internal procedures passed as actual arguments
using LLVM's `llvm.init.trampoline` / `llvm.adjust.trampoline`
intrinsics, which require an executable stack. On modern Linux
toolchains and security-hardened kernels that enforce W^X (Write XOR
Execute), this causes link-time failures (`ld.lld: error: ... requires
an executable stack`) or runtime `SEGV` from NX violations.
This patch introduces a runtime trampoline pool that allocates
trampolines from a dedicated `mmap`'d region instead of the stack. The
pool toggles page permissions between writable (for patching) and
executable (for dispatch), so the stack stays non-executable throughout.
On macOS, MAP_JIT and `pthread_jit_write_protect_np` are used for the
same effect. An i-cache flush (`__builtin___clear_cache` on Linux,
`sys_icache_invalidate` on macOS) is performed after each write→exec
transition.
The feature is gated behind a new driver flag, `-fsafe-trampoline` (off
by default), which threads through the frontend into the
`BoxedProcedurePass`. When enabled, the pass emits calls to
`_FortranATrampolineInit`, `_FortranATrampolineAdjust`, and
`_FortranATrampolineFree` instead of the legacy intrinsics. The legacy
path is completely untouched when the flag is off.
The pool is a singleton with a fixed capacity (default 1024 slots,
overridable via `FLANG_TRAMPOLINE_POOL_SIZE`). Slot size varies by
target (32 bytes on x86-64/AArch64, 48 on PPC64, 64 fallback). Each slot
holds a small architecture-specific stub, currently x86-64 (17 bytes,
using `r10` as the nest/static-chain register) and AArch64 (24 bytes,
using `x15`). The implementation compiles on all architectures but will
crash at runtime with a clear diagnostic if trampoline emission is
actually attempted on an unsupported target. This avoids breaking the
flang-rt build on e.g. RISC-V or PPC64.
Freed slots are poisoned (the callee pointer is overwritten with a
sentinel) and recycled into a freelist, so the pool can sustain
long-running programs that repeatedly create and destroy closures.
A few design choices worth calling out:
The runtime avoids all C++ runtime dependencies, no `std::mutex`, no
`operator new`, no function-local statics with hidden guard variables.
Locking is via flang-rt's own `Lock` / `CriticalSection`, memory is via
`AllocateMemoryOrCrash` / `FreeMemory`, and the singleton uses explicit
double-checked locking with a raw pointer. This was done so the
trampoline pool links cleanly in minimal / freestanding flang-rt
configurations.
`_FortranATrampolineFree` calls are inserted immediately before every
`func.return` in the enclosing host function. This is a conservative but
correct strategy. The trampoline handle cannot outlive the host's stack
frame since the closure captures the host's local variables by
reference.
The GNU_STACK note is verified via a dedicated integration test
(`safe-trampoline-gnustack.f90`) that compiles and links a Fortran
program using the runtime path, then inspects the ELF with
`llvm-readelf` to confirm the stack segment is `RW` (not `RWE`).
**Test coverage:**
- `flang/test/Driver/fsafe-trampoline.f90` — flag forwarding (on, off,
default)
- `flang/test/Fir/boxproc-safe-trampoline.fir` — FIR-level FileCheck for
emitted runtime calls
- `flang/test/Lower/safe-trampoline.f90` — end-to-end lowering
- `flang-rt/test/Driver/safe-trampoline-gnustack.f90` — GNU_STACK ELF
verification
Closes#182813
Co-authored-by: Sairudra More <moresair@pe31.hpc.amslabs.hpecorp.net>
LangRef currently specifies that non-byte-sized stores write an
unspecified bit pattern in the "padding", and that performing a
subsequent load with a different bitwidth is "undefined". This means
that storing an i1 value and then loading it as i8, the result is
"undefined" (whatever that is supposed to mean). These semantics are
quite unusual as they depend on the exact type a memory location has
been accessed with previously. I believe that frontends often do not
respect these semantics.
This PR proposes to instead specify that non-byte-sized loads
effectively act like like a byte sized `load` followed by `trunc nuw`,
and non-byte-sized stores act like a `zext` followed by a byte-sized
store. To the best of my knowledge, this matches the legalization
behavior of SDAG.
This does restrict possible codegen choices (e.g. a target couldn't
define these as `sext`/`trunc nsw` instead anymore), but it does not
appear that there is any interest in that in practice, given that SDAG
does not support it to this day.
This benchmark isn't very good at benchmarking `search_n`, since a good
`search_n` implementation can go through it in ~10 perfectly predictable
steps. We can drop it to avoid spending unnecessary resources. This also
fixes that the two benchmark sets have identical names.
Fixes#183832
This PR allows for modelling escape of parameters to global storage, and
dangling global storage.
Change summary:
1. Created `GlobalEscapeFact` as a subclass of `OriginEscapesFact`
2. Emit a `GlobalEscapeFact` for all origins with global-storage that
remain live at function exit.
3. Integrated into warning reporting as necessary, introducing the
groups `-Wlifetime-safety-dangling-global` and
`-Wlifetime-safety-dangling-global-moved`
4. Wrote sema tests for escape to a variety of global storage locations.
When the message ends with a newline. ...WithFormatv adds a newline
automatically.
Note that the ":x" style is lower case hex with 0x prefix. (see
llvm/include/llvm/Support/FormatProviders.h)
This change does not change uses where multiple chunks are emitted to
one line, or the message has embedded newlines. I want to deal with
these more complex cases later.
This is round 3 of N doing this, converting a few files at a time.
`formatter::parse` and `formatter::format` only have to accept
`basic_format_parse_context` and `basic_format_context` respectively,
which are only guaranteed to be provided via `<format>`. This allows us
to only declare the functions for `formatter<bool>` in `<vector>` and
define them if `<format>` is included. This reduces the amount of time
it takes to parse `<vector>` by ~15% on my system.
The "private global" terminology, likely came from
llvm/lib/IR/Mangler.cpp, is misleading: "private" is the opposite of
"global", and these prefixed symbols are not global in the object file
format sense (e.g. ELF has STB_GLOBAL while these symbols are always
STB_LOCAL). The term "internal symbol" better describes their purpose:
symbols for internal use by compilers and assemblers, not meant to be
visible externally.
This rename is a step toward adopting the "internal symbol prefix"
terminology agreed with GNU as
(https://sourceware.org/pipermail/binutils/2026-March/148448.html).
When the allocators use fancy pointers, the internal map of `deque`
stores `FancyPtr<T>` objects, and the previous strategy accessed these
objects via `const FancyPtr<const T>` lvalues, which usually caused core
language undefined behavior. Now `const_iterator` stores `FancyPtr<const
FancyPtr<T>>` instead of `FancyPtr<const FancyPtr<const T>>`, and ABI
break can happen when such two types have incompatible layouts.
This is necessary for reducing undefined behavior and `constexpr`
support for `deque` in C++26, and I currently don't want to provide any
way to opt-out of that behavior.
For `iterator`, the current strategy makes it store
`FancyPtr<FancyPtr<T>>`. But it would make more sense to also store
`FancyPtr<const FancyPtr<T>>` because we never modify the map via
`iterator`.
For some pathological combinations of allocators and fancy pointers, the
rebinding trick doesn't work. These cases are rejected by
`static_assert`.
The existing test coverage seems to be sufficient.
