[Clang] Fix BitInt padding clearing on big-endian targets (#215809)
This patch fixes the padding clearing logic of `_BitInt`s.
Before this patch, the clearing logic assumed little endian. But the
memory layout of BitInts differs between little and big endian:
- In LE, the occupied bits start from the lowest address and go on
contiguously up until the BitInt's declared size. The padding bits then
start from that point and go contiguously until the end of the storage
unit.
- In BE, since the byte order is reversed, the occupied bit interval is
not contiguous if the storage unit is larger than the BitInt's size.
Therefore, the logic must tell the two cases apart and perform the
calculations accordingly.
[flang][AliasAnalysis] Relax AliasAnalysis for host associated allocatables (#220826)
Relax AliasAnalysis for host associated allocatables.
FIR alias analysis conservatively returns MayAlias for values with
distinct host-associated origins because their storage may overlap
through EQUIVALENCE.
This change utilizes the fact that an equivalence object cannot be an
allocatable and relaxes the analysis for them. Specifically, if two
values have distinct host associated origin, neither is a pointer or a
target and at least one of them is an allocatable, we can safely declare
them NoAlias. Otherwise, we continue to conservatiely declare them
MayAlias.
Assisted-by: Codex
[AMDGPU] PromoteAlloca: split scalar accesses that span several elements
promoteAllocaToVector already splits a *vector* access across several
elements when it is a multiple of the element size, but a *scalar* access
had to be bitcastable to the element type, so an i64 load from an alloca
promoted to <8 x i32> was rejected as "not a supported access type" and
the object stayed in scratch.
Accept a scalar access that is a whole multiple of the element size and
route it through the existing subvector path, which already builds the
value from consecutive elements and bitcasts. Accesses with padding are
still rejected, since splitting those would put the pieces at the wrong
offsets, as are non-integer non-float types.
[CIR] Fix CIR tests after recent ABI change (#220749)
A recent change to unnamed bitfield classification for X86 targets
(https://github.com/llvm/llvm-project/pull/216777) broke several CIR
tests.
This change updates two of the failing tests to reflect the current
state. Further cleanup is needed in CIR after the ABI backward
compatibility issues are handled.
A third test was failing with an assertion because the unnamed bitfield
classification change exposed a problem in CIR's type mapper. We were
modeling unnamed zero-length bitfields as having the width of their
declared type rather than zero width. This triggered an assertion in the
ABI library after such bitfields were no longer skipped. This change now
reports zero width for such fields.
[MLIR][OpenMP] DeclareTargetInterface and DeclareTargetAttr cleanup
The changes introduced by this patch are intended to avoid triggering
multiple by name lookups to the "omp.declare_target" attribute every
time any data from the `DeclareTargetInterface` is queried, remove the
need for keeping multiple default values for the same data, clean up
the assembly format and generally improve the usage of the interface.
List of changes:
- `DeclareTargetInterface` only provides `setDeclareTarget` and
`getDeclareTarget` methods to handle the "omp.declare_target"
attribute, maintaining a single canonical way of accessing it.
- `DeclareTargetAttr` provides direct access to the capture clause and
device type enums, rather than wrapping them into an `Attribute`.
These are now mandatory as well. Both changes together make accessing
them more straightforward and simplify the attribute representation.
[flang][OpenACC] Emit module PARAMETERs as initialized linkonce_odr globals (#220666)
Emit an initialized linkonce_odr global from the module-file value in
each compilation unit that needs a module PARAMETER (follow USE
association so the initializer is not lost). Separately compiled uses
under OpenACC default(present) then keep the constant on the device
instead of treating a bodyless external as data that must already be
present.
Keep external linkage when the PARAMETER has an explicit !$acc declare
or a CUDA data attribute, which need a single shared device symbol
rather than a per-unit copy.
[OpenMP][CMake] Fix the device runtime build with LLVM_USE_SPLIT_DWARF (#220322)
Building with LLVM_USE_SPLIT_DWARF fails in the GPU runtimes:
ld.lld: error: -r and --gdb-index may not be used together
HandleLLVMOptions appends -Wl,--gdb-index to CMAKE_EXE_LINKER_FLAGS, and
libompdevice is an add_executable, so it inherits the flag. Its link is
not a real link at all: -flto -r -Wl,--lto-emit-llvm merges the objects
into a single bitcode file, for which a gdb index is meaningless.
Fix is to turn it off for the target.
Co-authored-by: Cursor <cursoragent at cursor.com>
[flang][OpenMP] Implement modifier set and modifier group verification
Introduce modifier set and group definitions, and include that information
in clause descriptors.
Extend the verification of syntactic properties to handle sets and groups.
[flang][OpenMP] Replace modifier verification with a generic one
Implement verification of syntactic properties (i.e. required, unique,
exclusive, ultimate) in a generic way, agnostic of the kind of element
to which these properties are applied. The goal here is to reuse it
for verifying clause properties in the future.
Refactor the existing modifier verification code to use it. Modify
the previous implementation (OmpVerifyModifiers) to always succeed
to reduce the amount of necessary changes.
[flang][test] Expect a single -rpath in fveclib.f90 ArmPL check (#220969)
Fixes a `check-flang` failure on main: `Flang :: Driver/fveclib.f90`.
#220697 consolidated `tools::addArchSpecificRPath()` down to a single
call site — it was removed from `ToolChain::addFlangRTLibPath()` and
from the `-fveclib=ArmPL` block in `tools::AddLinkerInputs()`, and one
unconditional call was hoisted to the end of `AddLinkerInputs()`. A link
line can therefore emit each candidate rpath at most once, so
`CHECK-RPATH-ARMPL` fails on its second `-rpath` match:
```
flang/test/Driver/fveclib.f90:59:27: error: CHECK-RPATH-ARMPL-SAME: expected string not found in input
! CHECK-RPATH-ARMPL-SAME: "-rpath"
^
```
The two matches only ever passed because `addArchSpecificRPath()` is a
pure function of the toolchain and the argument list, so the two former
[10 lines not shown]
[offload][l0] Report actual driver version through OL_DEVICE_INFO_DRIVER_VERSION (#218412)
The Level Zero plugin currently reports the Level Zero API version as
the driver version. Moreover, as the lookup table only includes API
versions up to `1.12`, newer versions (e.g. `1.15`) end up being
reported as Unknown.
Report the actual driver version instead:
- If the `zeIntelGetDriverVersionString` extension is available, use it.
This string may be more detailed than what `zeDriverGetProperties`
provides (e.g. hotfix suffix)
- If the above is not available, use
`zeDriverGetProperties().driverVersion`, an U32 value whose octets make
up major, minor & build numbers.
- The driver version is fetched once per context and stored in an
`std::string` inside of the `L0ContextTy`.
This is intended to match the behavior of Intel's Unified Runtime.
[5 lines not shown]
[offload][sycl] Introduce `DRIVER_ID` device property (#217562)
Prior to the introduction of liboffload contexts, Level Zero devices
under different driver instances used to each receive their own
`L0ContextTy`s.
https://github.com/llvm/llvm-project/pull/209144 introduced contexts,
which are designed to map to a single `ze_context` on L0.
`olCreateContext` accepts a user-defined device list and is restricted
to accept devices within a single platform. This restriction is
insufficient for L0 - passing devices from different driver instances is
allowed under this contract, but does not make sense on L0 as
`zeContextCreate` needs a concrete driver instance as a parameter.
Introduce a `DRIVER_ID` device property. On CUDA and AMD, it is always
equal to 0. On L0, it is a distinct integer for each driver instance. A
set of devices can be used to create a context if and only if they all
belong to the same platform and have the same DRIVER_ID.
[4 lines not shown]
[VectorCombine] Check call targets when folding deinterleave/interleave pairs (#219116)
Instruction::isSameOperationAs() intentionally compares operation shape
and
special state without requiring operand identity. For CallBase
instructions,
this means calls to different targets with otherwise compatible
signatures can
compare as equivalent.
This caused VectorCombine::foldDeinterleaveInterleavePair() to treat
same-signature intrinsics such as llvm.smax and llvm.smin as the same
operation
and incorrectly fold them into a single widened call.
Add an opt-in Instruction::CompareCallTargets operation-equivalence
flag. When
requested, isSameOperationAs() additionally requires
CallBase::getCalledOperand() to match. Existing callers retain the
[9 lines not shown]
[Clang][OpenMP] Lower assume directive's holds clause to llvm.assume (#220688)
Emit `@llvm.assume` for the OpenMP 5.1 `assume` directive's `holds()`
clause, enabling downstream optimizations. Previously the clause was
parsed but its condition discarded without effect. Side-effectful
conditions are skipped with a warning, matching the existing
`[[assume]]`/`__builtin_assume` behavior.
[AMDGPU] PromoteAlloca: split scalar accesses that span several elements
promoteAllocaToVector already splits a *vector* access across several
elements when it is a multiple of the element size, but a *scalar* access
had to be bitcastable to the element type, so an i64 load from an alloca
promoted to <8 x i32> was rejected as "not a supported access type" and
the object stayed in scratch.
Accept a scalar access that is a whole multiple of the element size and
route it through the existing subvector path, which already builds the
value from consecutive elements and bitcasts. Accesses with padding are
still rejected, since splitting those would put the pieces at the wrong
offsets, as are non-integer non-float types.
[AMDGPU] PromoteAlloca: flatten homogeneous structs to vectors (#217055)
getVectorTypeForAlloca() peeled nested ArrayType and one inner
FixedVectorType, but stopped at any StructType. An alloca of an array of
structs was therefore rejected with "Cannot convert type to vector" and
fell back to scratch, even when the struct was a trivial wrapper around
a scalar.
Peel structs too, but only when every field has the same type and the
struct has no padding, so flattened elements keep the byte offsets the
surrounding index arithmetic assumes. Structs with differing field types
or with padding are left alone.
