At the time of the implementation of
[N3007](https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3007.htm) in
Clang, when an array type was specified, an error was emitted unless the
deduced type was a `char *`.
After further inspection in the C standard, it turns out that the
inferred type of an `char[]` should be deduced to a `char *`, which
should emit an error if an array type is specified with `auto`.
This now invalidates the following cases:
```c
auto s1[] = "test";
auto s2[4] = "test";
auto s3[5] = "test";
```
Fixes#162694
Splitting out some work from #178454; this covers the enums for
early exit loop type (none, readonly, readwrite) and the style
used (readonly with multiple exit blocks, or masking with the
last iteration done in scalar code), along with changing the early
exit recipe detection to suit moving the transform for handling
early exit readwrite loops earlier in the vplan pipeline.
Add SCEVUseVisitor, a new visitor class where all visit methods receive
a SCEVUse instead of a const SCEV*. Use it for SCEVExpander, so it can
use use-specific flags in the future.
PR: https://github.com/llvm/llvm-project/pull/188863
We previously didn’t diagnose attempts to return an initializer list from
a lambda with an explicit return type of `void`. This patch fixes that. It also
cleans up the error message so it actually says "lambda" instead of "block".
Fixes#188661
Signed off by: Kartik
Add support for `[[msvc::forceinline]]` and
`[[msvc::forceinline_calls]]`.
`[[msvc::forceinline]]` is equivalent to Microsoft's `__forceinline`
when placed before a function declaration.
Unlike `__forceinline`, `[[msvc::forceinline]]` works with lambdas.
`[[msvc::forceinline_calls]]` is simliar to `[[clang::always_inline]]`
but only works on statements.
Both are implemented as aliases of `[[clang::always_inline]]` with
special checks.
Fixes#186539.
Related: #183340
Upstream from swiftlang/llvm-project@721e6a3 with some modifications.
Since __counted_by and related attributes aren't supported upstream yet
in function signatures, this only upstreams the format part — YAML
parsing, binary serialization, and deserialization. Semantic application
is a follow-up.
Modifications from downstream:
- Renamed local YAML struct from `BoundsSafety` to `BoundsSafetyNotes`
to avoid name collision with `Param::BoundsSafety` field (downstream
fixed this in a subsequent commit)
- `Level` in `BoundsSafetyNotes` is now `std::optional<unsigned>` so we
can actually tell apart "user didn't write Level:" from "Level: 0"
- `asdf_sized` and `asdf_sized_n` use `void *buf` — makes more sense for
sized_by
- Added `asdf_counted_indirect` with `int **` and `Level: 1` to test the
indirection level path
- Removed a vacuous assert (`CountedBy == 0`, always true for unsigned)
- Added `operator!=` for `BoundsSafetyInfo` to match other types in
`Types.h`
- Added doc comments for `LevelAudited` and `Level`
In some environments like swiftlang, the `''` causes the command used to
drain the init sequence of the ConPTY to fail. Replacing with a `cls`
invocation removes the need for quotation marks and works just as well.
Add a FileCheck test covering the 'expected at least one input' error in
ReduceOp::verify(). The companion 'expected at least one output' check
was dead code: SameVariadicOperandSize fires first whenever
inputs.size() \!= inits.size(), and when both are empty the input check
fires first; remove the unreachable branch.
Assisted-by: Claude Code
This reverts commit 1418f80.
The change can cause an infinite rewrite loop when
ForwardConcatInsertSliceDest interacts with
FoldEmptyTensorWithExtractSliceOp.
The isTreeTinyAndNotFullyVectorizable check for 2-node trees
(insertelement root + gather child) was too aggressive: it rejected
trees even when LoadEntriesToVectorize was non-empty, preventing
gathered loads from being vectorized into masked loads/strided loads, etc.
Reviewers: hiraditya, RKSimon
Pull Request: https://github.com/llvm/llvm-project/pull/190181
The Exact SIV test and the Exact RDIV test behave almost identically,
except that the Exact SIV test also explores the directions in the final
step. This patch consolidates the two duplicate implementations into a
single function that can be used by both tests. While this change
slightly affects things like debug output and metrics, it is not
intended to alter the actual test results.
The main change is to eliminate the use of "Argument" terminology when
dealing with overloaded types since overloaded types can be either
argument or return values, and some additional renaming for clarity.
1. Rename `Tys` argument to various intrinsic APIs to `OverloadTys` to
better reflect its meaning.
2. Rename `IITDescriptorKind::Argument` to
`IITDescriptorKind::Overloaded` to better convey that it's an overloaded
type. Removed "Argument" suffix for other kinds for dependent types.
3. Rename `ArgKind` to `AnyKind`, `getArgumentNumber` to
`getOverloadIndex`, `getArgumentKind` to `getOverloadKind`,
`getRefArgNumber` to `getRefOverloadIndex`, and `IIT_ARG` to `IIT_ANY`.
4. Rename `IIT_ANYPTR` (used to represent a pointer qualified with
address space) to `IIT_PTR_AS` to clearly distinguish it from
`llvm_anyptr_ty`
5. Change the packing of [ref overload index & overload index] for
`VecOfAnyPtrsToElt` to pack the overload index into the lower bits, so
we can use the `getOverloadIndex` function to get the overload index.
This ends up being a pretty trivial amount of work, since we just have
to forward the initialization for a union on to the 'active' field,
which this patch does.
This functionality is described in the Itanium C++ABI 2.5.2 (and is also
where the test comes from). See also VTableBuilder.cpp's documentation
on the declaration of IsOverriderUsed for further details.
However, the explaination is:
When B and C are declared, A is a primary base in each case, so although
vcall offsets are allocated in the A-in-B and A-in-C vtables, no this
adjustment is required and no thunk is generated. However, inside D
objects, A is no longer a primary base of C, so if we allowed calls to
C::f() to use the copy of A's vtable in the C subobject, we would need
to adjust this from C* to B::A*, which would require a third-party
thunk. Since we require that a call to C::f() first convert to A*,
C-in-D's copy of A's vtable is never referenced, so this is not
necessary.
The short of that is: there is no way to call these, so we just emit a
nullptr rather than the required thunk.
This adds the CalculateLevelOfDetail and CalculateLevelOfDetailUnclamped
methods to Texture2D using the establish pattern used for other methods.
Assisted-by: Gemini
Sometimes we use array of bytes to represent `_BitInt` types in memory.
When this is the case the lowered array filler expression reaches
`ConstantEmitter::emitForMemory` already with memory type which will be
array of i8 instead of a single iN, so `cast<llvm::ConstantInt>` was
failing within `ConstantEmitter::emitForMemory`. This patch fixes the
assertion failure by not attempting any type changes if the type is
right already.
Fixes https://github.com/llvm/llvm-project/issues/189643
Assisted-by: claude in FileCheck CHECK lines fixing
Fixes#181643
For queries like `isKnownToBeAPowerOfTwo(V, OrZero=true)`, if an operand
is known to be "pow2-or-zero" but not strictly non-zero power-of-two,
the min/max case currently returns false even when the result remains
pow2-or-zero.
For instance:
- `A = select cond, 4, 0` (A is pow2-or-zero)
- `R = umin(A, 16)`
`R` is always in `{0, 4}` and querying `isKnownToBeAPowerOfTwo(R,
OrZero=true)` should be true.
Added unitests for baseline and failing case and now propagating
correctly to `OrZero` and `DemandedElts`
For all targets, (V)PADDB is always as fast as (V)PSLLW (usually faster)
- and usually as fast as (V)PAND, and avoids having to load a mask - so
for shift lefts by 2, a pair of (V)PADDB is a better choice vs
(V)PSLLW+(V)PAND
This is only necessary if we're avoiding a (V)PAND mask - otherwise we
just need a single (V)PSLLW.
The pass pipeline differs across targets, so make this test use
one specific pipeline, instead of trying to cater to cross-target
differences. Those differences are not relevant to the intent of
the test.
In this patch I am adding the missing target hooks required for the
liveness analysis to run on AArch64. These are
- getFlagsReg()
- getRegsUsedAsParams()
- getDefaultLiveOut()
- getGPRegs()
- isCleanRegXOR()
I am also introducing the following API in LivenessAnalysis
- BitVector getLiveIn/Out(const MCInst &)
- MCPhysReg scavengeRegFromState(BitVector &)
My intention is to allow the LongJmp pass scavenge usable registers when
injecting code.
The isTreeTinyAndNotFullyVectorizable check for 2-node trees
(insertelement root + gather child) was too aggressive: it rejected
trees even when LoadEntriesToVectorize was non-empty, preventing
gathered loads from being vectorized into masked loads/strided loads, etc.
Reviewers: RKSimon, hiraditya
Pull Request: https://github.com/llvm/llvm-project/pull/190040
Extend the existing any_extend(bswap i16) -> rev16 combine to also
handle zero_extend. REV16 preserves a zero upper half, so for i16 loads
this saves one instruction: ldrh+rev+lsr#16 -> ldrh+rev16.
Introduce common infrastructure for runtimes that determines compiler
resource path locations. These variables introduced are:
* RUNTIMES_OUTPUT_RESOURCE_DIR
* RUNTIMES_INSTALL_RESOURCE_PATH
That contain the location for the compiler resource path (typically
`lib/clang/<version>`) in the build tree and the install tree (the
latter relative to CMAKE_INSTALL_PREFIX).
Additionally, define
* RUNTIMES_OUTPUT_RESOURCE_LIB_DIR
* RUNTIMES_INSTALL_RESOURCE_LIB_PATH
as for the location of clang/flang version-locked libraries (typically
`lib${LLVM_LIBDIR_SUFFIX}/<targer-triple>`, but also depends on `APPLE`
and `LLVM_ENABLE_PER_TARGET_RUNTIME_DIR`). This code is moved from
flang-rt and initially becomes its only user.
Refactored out of #171610 as requested
[here](https://github.com/llvm/llvm-project/pull/171610#discussion_r2687382481).
Extracted `get_runtimes_target_libdir_common` from compiler-rt as
requested
[here](https://github.com/llvm/llvm-project/pull/171610#discussion_r2689565634).
Added TODO comments to all runtimes as requested
[here](https://github.com/llvm/llvm-project/pull/171610#issuecomment-3789598635).
Implements isMemcpyEquivalentSpecialMember in CIR codegen so that
trivial copy/move constructors and defaulted union copy/move ops emit a
cir.copy directly instead of making a real constructor call. The logic
is shared with OG codegen by moving the implementation into ASTContext,
where it also gains the pointer field protection (PFP) check that was
previously missing in CIR.
Initially added in #187709. It was reverted in #188833, because
[llvm-clang-x86_64-sie-win](https://lab.llvm.org/buildbot/#/builders/46/builds/32873)
was failing in
`cross-project-tests/debuginfo-tests/dexter-tests/nrvo.cpp`.
The test passed for me locally. After checking on another machine, I
found that `S_DEFRANGE_REGISTER_REL_INDIR` is only supported by
dbgeng/WinDbg from Windows 10.0 Build 19041 (released 2020) onwards.
SDKs before this will fail to read the value. That buildbot is on
Windows 10.0 Build 17763.
I'm not sure if we should make the generation of that record
conditional. Debuggers that can't read the record will skip it. They'll
still see that there's some local variable, but won't be able to display
the value.
As far as I know, users of older Windows 10 builds should be able to
install a newer Windows SDK and use the WinDbg from that version. But I
haven't tested that.
For whatever reason we ended up with register/register but the first
register just had the second register folder in it.
Move the files up one level so we have register/<test files>.
This patch uses DestructiveBinaryShImmUnpred (which was previously
unused as far as I could tell) to define pseudos for arithmetic
immediate instructions such as ADD (immediate), which allows using
MOVPRFX with these instructions.
