Add AMDGPUTargetLowering::canCreateUndefOrPoisonForTargetNode handler
and tag BFE_I32/U32 nodes as they can only propagate poison, not create
poison/undef.
Fighting some of the remaining regressions in #152107
Reland of https://github.com/llvm/llvm-project/pull/147381
Added changes to fix observed BuildBot failures:
* CMake version (reduced minimum to `3.20`, was: `3.22`)
* GoogleTest linking (missing `./build/lib/libllvm_gtest.a`)
* Related header issue (missing `#include
"llvm/Support/raw_os_ostream.h"`)
Original message
Description
===========
OpenMP Tooling Interface Testing Library (ompTest) ompTest is a unit testing framework for testing OpenMP implementations. It offers a simple-to-use framework that allows a tester to check for OMPT events in addition to regular unit testing code, supported by linking against GoogleTest by default. It also facilitates writing concise tests while bridging the semantic gap between the unit under test and the OMPT-event testing.
Background
==========
This library has been developed to provide the means of testing OMPT implementations with reasonable effort. Especially, asynchronous or unordered events are supported and can be verified with ease, which may prove to be challenging with LIT-based tests. Additionally, since the assertions are part of the code being tested, ompTest can reference all corresponding variables during assertion.
Basic Usage
===========
OMPT event assertions are placed before the code, which shall be tested. These assertion can either be provided as one block or interleaved with the test code. There are two types of asserters: (1) sequenced "order-sensitive" and (2) set "unordered" assserters. Once the test is being run, the corresponding events are triggered by the OpenMP runtime and can be observed. Each of these observed events notifies asserters, which then determine if the test should pass or fail.
Example (partial, interleaved)
==============================
```c++
int N = 100000;
int a[N];
int b[N];
OMPT_ASSERT_SEQUENCE(Target, TARGET, BEGIN, 0);
OMPT_ASSERT_SEQUENCE(TargetDataOp, ALLOC, N * sizeof(int)); // a ?
OMPT_ASSERT_SEQUENCE(TargetDataOp, H2D, N * sizeof(int), &a);
OMPT_ASSERT_SEQUENCE(TargetDataOp, ALLOC, N * sizeof(int)); // b ?
OMPT_ASSERT_SEQUENCE(TargetDataOp, H2D, N * sizeof(int), &b);
OMPT_ASSERT_SEQUENCE(TargetSubmit, 1);
OMPT_ASSERT_SEQUENCE(TargetDataOp, D2H, N * sizeof(int), nullptr, &b);
OMPT_ASSERT_SEQUENCE(TargetDataOp, D2H, N * sizeof(int), nullptr, &a);
OMPT_ASSERT_SEQUENCE(TargetDataOp, DELETE);
OMPT_ASSERT_SEQUENCE(TargetDataOp, DELETE);
OMPT_ASSERT_SEQUENCE(Target, TARGET, END, 0);
#pragma omp target parallel for
{
for (int j = 0; j < N; j++)
a[j] = b[j];
}
```
References
==========
This work has been presented at SC'24 workshops, see: https://ieeexplore.ieee.org/document/10820689
Current State and Future Work
=============================
ompTest's development was mostly device-centric and aimed at OMPT device callbacks and device-side tracing. Consequentially, a substantial part of host-related events or features may not be supported in its current state. However, we are confident that the related functionality can be added and ompTest provides a general foundation for future OpenMP and especially OMPT testing. This PR will allow us to upstream the corresponding features, like OMPT device-side tracing in the future with significantly reduced risk of introducing regressions in the process.
Build
=====
ompTest is linked against LLVM's GoogleTest by default, but can also be built 'standalone'. Additionally, it comes with a set of unit tests, which in turn require GoogleTest (overriding a standalone build). The unit tests are added to the `check-openmp` target.
Use the following parameters to perform the corresponding build:
`LIBOMPTEST_BUILD_STANDALONE` (Default: ${OPENMP_STANDALONE_BUILD})
`LIBOMPTEST_BUILD_UNITTESTS` (Default: OFF)
---------
Co-authored-by: Jan-Patrick Lehr <JanPatrick.Lehr@amd.com>
Co-authored-by: Joachim <protze@rz.rwth-aachen.de>
Co-authored-by: Joachim Jenke <jenke@itc.rwth-aachen.de>
orc_rt_WrapperFunctionResult is a byte-buffer with inline storage and a
builtin error state. It is intended as a general purpose return type for
functions that return a serialized result (e.g. for communication across
ABIs or via IPC/RPC).
orc_rt_WrapperFunctionResult contains a small amount of inline storage,
allowing it to avoid heap-allocation for small return types (e.g. bools,
chars, pointers).
It broke the build:
compiler-rt/lib/hwasan/hwasan_thread.cpp:177:11: error: unknown type name 'ssize_t'; did you mean 'size_t'?
177 | (ssize_t)unique_id_, (void *)this, (void *)stack_bottom(),
| ^~~~~~~
| size_t
> This change addresses CodeQL format-string warnings across multiple
> sanitizer libraries by adding explicit casts to ensure that printf-style
> format specifiers match the actual argument types.
>
> Key updates:
> - Cast pointer arguments to (void*) when used with %p.
> - Use appropriate integer types and specifiers (e.g., size_t -> %zu,
> ssize_t -> %zd) to avoid mismatches.
> - Fix format specifier mismatches across xray, memprof, lsan, hwasan,
> dfsan.
>
> These changes are no-ops at runtime but improve type safety, silence
> static analysis warnings, and reduce the risk of UB in variadic calls.
This reverts commit d3d5751a39452327690b4e011a23de8327f02e86.
## Change:
* Added `--dump-dot-func` command-line option that allows users to dump
CFGs only for specific functions instead of dumping all functions (the
current only available option being `--dump-dot-all`)
## Usage:
* Users can now specify function names or regex patterns (e.g.,
`--dump-dot-func=main,helper` or `--dump-dot-func="init.*`") to generate
.dot files only for functions of interest
* Aims to save time when analysing specific functions in large binaries
(e.g., only dumping graphs for performance-critical functions identified
through profiling) and we can now avoid reduce output clutter from
generating thousands of unnecessary .dot files when analysing large
binaries
## Testing
The introduced test `dump-dot-func.test` confirms the new option does
the following:
- [x] 1. `dump-dot-func` can correctly filter a specified functions
- [x] 2. Can achieve the above with regexes
- [x] 3. Can do 1. with a list of functions
- [x] No option specified creates no dot files
- [x] Passing in a non-existent function generates no dumping messages
- [x] `dump-dot-all` continues to work as expected
This patch does two things:
- Remove exception specifications of `= default`ed special member
functions
- `= default` special member functions
The first part is NFC because the explicit specification does exactly
the same as the implicit specification. The second is NFC because it
does exactly what the `= default`ed special member does.
Win/ASan relies on the runtime's functions being 16-byte aligned so it
can intercept them with hotpatching. This used to be true (but not
guaranteed) until #149444.
Passing /hotpatch will give us enough alignment and generally ensure
that the functions are hotpatchable.
Drop poison generating flags on trunc when distributing trunc over
add/sub/or. We need to do this since for example
(add (trunc nuw A), (trunc nuw B)) is more poisonous than
(trunc nuw (add A, B))).
In some situations it is pessimistic to drop the flags. Such as
if the add in the example above also has the nuw flag. For now we
keep it simple and always drop the flags.
Worth mentioning is that we drop the flags when cloning
instructions and rebuilding the chain. This is done after the
"allowsPreservingNUW" checks in ConstantOffsetExtractor::Extract.
So we still take the "trunc nuw" into consideration when determining
if nuw can be preserved in the gep (which should be ok since that
check also require that all the involved binary operations has nuw).
Fixes#154116
This handles constant folding for the AVX2 per-element shift intrinsics, which handle out of bounds shift amounts (logical result = 0, arithmetic result = signbit splat)
AVX512 intrinsics will follow in follow up patches
First stage of #154287
This is a weird special case added in 2015, simplifying an even older
condition. It is a no-op for ELF (isExternal is always false) and seems
unneeded for non-ELF.
Similay to
94655dc8ae
The difference is that in LoongArch, the ALIGN is synthesized when the
alignment is >4, (instead of >=4), and the number of bytes inserted is
`sec->addralign - 4`.
extractSubregFromImm previously would sign extend the 16-bit subregister
extracts, but not the 32-bit. We try to consistently store immediates
as sign extended, since not doing it can result in misreported
isInlineImmediate checks.
Since src_{private|shared}_{base|limit} registers are added and
are not artifical compiler happily uses it when it can. In HW
these registers do not exist and the encoding belongs to their
64-bit super-register or 32-bit low register. Same instructions
will produce relocation if run through asm.
This patch updates the TMA Tensor prefetch Op
to add support for im2col_w/w128 and tile_gather4 modes.
This completes support for all modes available in Blackwell.
* lit tests are added for all possible combinations.
* The invalid tests are moved to a separate file with more coverage.
Signed-off-by: Durgadoss R <durgadossr@nvidia.com>
This patch adds basic assembler and MC layer infrastructure for
RISC-V big-endian targets (riscv32be/riscv64be):
- Register big-endian targets in RISCVTargetMachine
- Add big-endian data layout strings
- Implement endianness-aware fixup application in assembler
backend
- Add byte swapping for data fixups on BE cores
- Update MC layer components (AsmInfo, MCTargetDesc, Disassembler,
AsmParser)
This provides the foundation for BE support but does not yet include:
- Codegen patterns for BE
- Load/store instruction handling
- BE-specific subtarget features
These are almost all for internal-developer-users only so "look at
debugserver.cpp" wasn't unreasonable, but we rarely add any new options
so a simple list of all recognized options isn't a burden to throw in
the help method.
This change addresses CodeQL format-string warnings across multiple
sanitizer libraries by adding explicit casts to ensure that printf-style
format specifiers match the actual argument types.
Key updates:
- Cast pointer arguments to (void*) when used with %p.
- Use appropriate integer types and specifiers (e.g., size_t -> %zu,
ssize_t -> %zd) to avoid mismatches.
- Fix format specifier mismatches across xray, memprof, lsan, hwasan,
dfsan.
These changes are no-ops at runtime but improve type safety, silence
static analysis warnings, and reduce the risk of UB in variadic calls.
In 88f409194, we changed the way the crashlog scripted process was
launched since the previous approach required to parse the file twice,
by stopping at entry, setting the crashlog object in the middle of the
scripted process launch and resuming it.
Since then, we've introduced SBScriptObject which allows to pass any
arbitrary python object accross the SBAPI boundary to another scripted
affordance.
This patch make sure of that to include the parse crashlog object into
the scripted process launch info dictionary, which eliviates the need to
stop at entry.
Signed-off-by: Med Ismail Bennani <ismail@bennani.ma>
Signed-off-by: Med Ismail Bennani <ismail@bennani.ma>
libstdc++ can be configured to default to a different C++11 ABI, and
when the system that is used to build clang has a different default than
the system used to build a clang plugin, that leads to uses of different
ABIs, leading to breakage (missing symbols) when using clang APIs that
use types like std::string.
We arbitrarily choose to default to the old ABI, but the user can opt-in
to the new ABI. The important part is that whichever is picked is
reflected in llvm-config's output.
The Generic_GCC::GCCInstallationDetector class picks the GCC installation directory with the largest version number. Since the location of the libstdc++ include directories is tied to the GCC version, this can break C++ compilation if the libstdc++ headers for this particular GCC version are not available. Linux distributions tend to package the libstdc++ headers separately from GCC. This frequently leads to situations in which a newer version of GCC gets installed as a dependency of another package without installing the corresponding libstdc++ package. Clang then fails to compile C++ code because it cannot find the libstdc++ headers. Since libstdc++ headers are in fact installed on the system, the GCC installation continues to work, the user may not be aware of the details of the GCC detection, and the compiler does not recognize the situation and emit a warning, this behavior can be hard to understand - as witnessed by many related bug reports over the years.
The goal of this work is to change the GCC detection to prefer GCC installations that contain libstdc++ include directories over those which do not. This should happen regardless of the input language since picking different GCC installations for a build that mixes C and C++ might lead to incompatibilities.
Any change to the GCC installation detection will probably have a negative impact on some users. For instance, for a C user who relies on using the GCC installation with the largest version number, it might become necessary to use the --gcc-install-dir option to ensure that this GCC version is selected.
This seems like an acceptable trade-off given that the situation for users who do not have any special demands on the particular GCC installation directory would be improved significantly.
This patch does not yet change the automatic GCC installation directory choice. Instead, it does introduce a warning that informs the user about the future change if the chosen GCC installation directory differs from the one that would be chosen if the libstdc++ headers are taken into account.
See also this related Discourse discussion: https://discourse.llvm.org/t/rfc-take-libstdc-into-account-during-gcc-detection/86992.
This patch reapplies #145056. The test in the original PR did not specify a target in the clang RUN line and used a wrong way of piping to FileCheck.
Start considering !amdgpu.no.remote.memory.access and
!amdgpu.no.fine.grained.host.memory metadata when deciding to expand
integer atomic operations. This does not yet attempt to accurately
handle fadd/fmin/fmax, which are trickier and require migrating the
old "amdgpu-unsafe-fp-atomics" attribute.
System scope atomics need to use cmpxchg loops if we know
nothing about the allocation the address is from.
aea5980e26e6a87dab9f8acb10eb3a59dd143cb1 started this, this
expands the set to cover the remaining integer operations.
Don't expand xchg and add, those theoretically should work over PCIe.
This is a pre-commit which will introduce performance regressions.
Subsequent changes will add handling of new atomicrmw metadata, which
will avoid the expansion.
Note this still isn't conservative enough; we do need to expand
some device scope atomics if the memory is in fine-grained remote
memory.
`NumFiltered` is the number of elements in all vectors in a map.
It is ever compared to 1, which is equivalent to checking if the map
contains exactly one vector with exactly one element.
All targets are included by Intrinsics.td so we should name things
carefully to avoid interfering with other targets.
Copy one class that LoongArch was also using.
### Problem
PR #142944 introduced a new canonicalization pattern which caused
failures in the following GPU-related integration tests:
-
mlir/test/Integration/GPU/CUDA/TensorCore/sm80/transform-mma-sync-matmul-f16-f16-accum.mlir
-
mlir/test/Integration/GPU/CUDA/TensorCore/sm80/transform-mma-sync-matmul-f32.mlir
The issue occurs because the new canonicalization pattern can generate
multi-dimensional `vector.from_elements` operations (rank > 1), but the
GPU lowering pipelines were not equipped to handle these during the
conversion to LLVM.
### Fix
This PR adds `vector::populateVectorFromElementsLoweringPatterns` to the
GPU lowering passes that are integrated in `gpu-lower-to-nvvm-pipeline`:
- `GpuToLLVMConversionPass`: the general GPU-to-LLVM conversion pass.
- `LowerGpuOpsToNVVMOpsPass`: the NVVM-specific lowering pass.
Co-authored-by: Yang Bai <yangb@nvidia.com>
Parse the `Inst` and `SoftField` fields once and store them in
`InstructionEncoding` so that we don't parse them every time
`getMandatoryEncodingBits()` is called.
Adds support for the Error class, Expected class template, and related
APIs that will be used for error propagation and handling in the new ORC
runtime.
The implementations of these types are cut-down versions of similar APIs
in llvm/Support/Error.h. Most advice on llvm::Error and llvm::Expected
(e.g. from the LLVM Programmer's manual) applies equally to
orc_rt::Error and orc_rt::Expected.
Ported from the old ORC runtime at compiler-rt/lib/orc.
Currently we only allow folding not (cmp eq) -> icmp ne if the not is
the only user of the compare.
However a common scenario is that some select might also use the
compare. We can still fold the not if we also swizzle the arms of the
selects.
This helps avoid regressions in #150368
libclc sequential build issue addressed in commit 0c21d6b4c8ad is
specific to cmake MSVC generator. Therefore, this PR avoids creating a
large number of targets when a non-MSVC generator is used, such as the
Ninja generator, which is used in pre-merge CI on Windows in
llvm-project repo. We plan to migrate from MSVC generator to Ninja
generator in our downstream CI to fix flaky cmake bug `Cannot restore
timestamp`, which might be related to the large number of targets.
This patch adds setters to the SBStruturedData class to be able to
initialize said object from the client side directly.
Signed-off-by: Med Ismail Bennani <ismail@bennani.ma>
The CrossDSOCFI pass runs on the full LTO module and fills in the
body of __cfi_check. This function must have the correct attributes in
order to be compatible with the rest of the program. For example, when
building with -mbranch-protection=standard, the function must have the
branch-target-enforcement attribute, which is normally added by Clang.
When __cfi_check is missing, CrossDSOCFI will give it the default set
of attributes, which are likely incorrect. Therefore, emit __cfi_check
to the full LTO part, where CrossDSOCFI will see it.
Reviewers: efriedma-quic, vitalybuka, fmayer
Reviewed By: efriedma-quic
Pull Request: https://github.com/llvm/llvm-project/pull/154833
Flang currently doesn't build in debug mode on GCC 15 due to missing
dynamic libraries in some CMakeLists.txt files, and OpenMP doesn't link
in debug mode due to the atomic library pulling in libstdc++ despite an
incomplete attempt in the CMakeLists.txt to disable glibcxx assertions.
This PR fixes these issues and allows Flang and the OpenMP runtime to
build and link on GCC 15 in debug mode.
---------
Co-authored-by: ronlieb <ron.lieberman@amd.com>
As the FIXME says, we might generate the wrong code to decode an
instruction if it had an operand with no encoding bits. An example is
M68k's `MOV16ds` that is defined as follows:
```
dag OutOperandList = (outs MxDRD16:$dst);
dag InOperandList = (ins SRC:$src);
list<Register> Uses = [SR];
string AsmString = "move.w\t$src, $dst"
dag Inst = (descend { 0, 1, 0, 0, 0, 0, 0, 0, 1, 1 },
(descend { 0, 0, 0 }, (operand "$dst", 3)));
```
The `$src` operand is not encoded, but what we see in the decoder is:
```C++
tmp = fieldFromInstruction(insn, 0, 3);
if (!Check(S, DecodeDR16RegisterClass(MI, tmp, Address, Decoder)))
{ return MCDisassembler::Fail; }
if (!Check(S, DecodeSRCRegisterClass(MI, insn, Address, Decoder)))
{ return MCDisassembler::Fail; }
return S;
```
This calls DecodeSRCRegisterClass passing it `insn` instead of the value
of a field that doesn't exist. DecodeSRCRegisterClass has an
unconditional llvm_unreachable inside it.
New decoder looks like:
```C++
tmp = fieldFromInstruction(insn, 0, 3);
if (!Check(S, DecodeDR16RegisterClass(MI, tmp, Address, Decoder)))
{ return MCDisassembler::Fail; }
return S;
```
We're still not disassembling this instruction right, but at least we no
longer have to provide a weird operand decoder method that accepts
instruction bits instead of operand bits.
See #154477 for the origins of the FIXME.
I'm trying to remove the redirection in SmallSet.h:
template <typename PointeeType, unsigned N>
class SmallSet<PointeeType*, N> : public SmallPtrSet<PointeeType*, N>
{};
to make it clear that we are using SmallPtrSet. There are only
handful places that rely on this redirection.
Now, this unit test is unique in that supply multiple key types via
TYPED_TESTS.
This patch adds UniversalSmallSet to work around the problem.
I'm trying to remove the redirection in SmallSet.h:
template <typename PointeeType, unsigned N>
class SmallSet<PointeeType*, N> : public SmallPtrSet<PointeeType*, N>
{};
to make it clear that we are using SmallPtrSet. There are only
handful places that rely on this redirection.
This patch replaces SmallSet to SmallPtrSet where the element type is
a pointer.
insertParsePoints collects live variables and then deduplicate them
while retaining the original insertion order, which is exactly what
SetVector is designed for. This patch replaces SmallVector with
SetSmallVector while deleting unique_unsorted.
While we are at it, this patch reduces the number of inline elements
to a reasonable level for linear search.
When multiple assumed size variable are used in a kernel with dynamic
shared memory, each variable use the 0 offset. Update the pass to
account for that.
```
attributes(global) subroutine testany( a )
real(4), shared :: smasks(*)
real(8), shared :: dmasks(*)
end subroutine
```
If an encoding has a custom decoder, the decoder is assumed to be
"complete" (always succeed) if hasCompleteDecoder field is true. We
determine this when constructing InstructionEncoding.
If the decoder for an encoding is *generated*, it always succeeds if
none of the operand decoders can fail. The latter is determined based on
the value of operands' DecoderMethod/hasCompleteDecoder. This happens
late, at table construction time, making the code harder to follow.
This change moves this logic to the InstructionEncoding constructor.
Instead of interleaving the pseudo definitions and their patterns,
define all the pseudos together and all the patterns together.
Add IsRV32 predicate to the patterns.
Summary:
The `__builtin_shufflevector` call would return a GCC vector in all
cases where the vector type was increased. Change this to preserve
whether or not this was an extended vector.
Fixes: https://github.com/llvm/llvm-project/issues/107981
This patch works towards consolidating all Clang debug-info into the
`clang/test/DebugInfo` directory
(https://discourse.llvm.org/t/clang-test-location-of-clang-debug-info-tests/87958).
Here we move only the `clang/test/CodeGenObjC` tests.
The list of files i came up with is:
1. searched for anything with `*debug-info*` in the filename
2. searched for occurrences of `debug-info-kind` in the tests
When trying to add a new diagnostic category (e.g. #154618) I discovered
`clang-format` really wanted to reformat these files.
My initial attempt was just to suppress the reformatting with `//
clang-format (on|off)` directives but reviewers preferred just
reformatting the files so these two files have been completely
reformatted.
`clang-format` has been disabled for the enum that declares the
`DIAG_START_*` constants because its much less readable after
formatting.
Move the logic to expand SCEVs directly to a late VPlan transform that
expands SCEVs in the entry block. This turns VPExpandSCEVRecipe into an
abstract recipe without execute, which clarifies how the recipe is
handled, i.e. it is not executed like regular recipes.
It also helps to simplify construction, as now scalar evolution isn't
required to be passed to the recipe.
When a typedef is declared within a templated class, clang incorrectly
assigns the typedef to the compilation unit (CU) scope rather than the
intended scope of the templated class. This issue arises because, during
the creation of the typedef, the context lookup in the RegionMap fails
to locate the templated class, despite its prior creation.
The problem stems from the way the context is stored in the RegionMap.
When handling templated types, the current implementation stores the
class specialization rather than the templated declaration itself. This
leads to a mismatch when attempting to retrieve the context for the
typedef.
To address this issue, the solution involves modifying the
CreatedLimitedType() function. Specifically, when a struct or class is a
templated type, we should store the actual templated declaration in the
RegionMap instead of the class specialization. This ensures that
subsequent lookups for context, such as those needed for typedef
declarations, correctly identify the templated class scope.
Fixes https://github.com/llvm/llvm-project/issues/91451
The refactoring of ComputePTXValueVTs in #154476 caused the complier to
no longer crash when lowering i256 and i96. This has caused a few tests
to unexpectedly pass.
Update these tests and tweak how we emit parameter declarations to
correctly lower these types.
Improve the `StringRef` summary formatter in the following ways:
* inherit adherence to the `target.max-string-summary-length` setting
* support non-printable bytes (such as null bytes, and any other binary data)
With the previous implementation, some non-printable bytes would raise a
Python exception.
Adds a `--defaults`/`-d` flag to `settings show`. This mode will _optionally_ show a
setting's default value. In other words, this does not always print a default value for
every setting.
A default value is not shown when the current value _is_ the default.
Note: some setting types do not print empty or invalid values. For these setting types,
if the default value is empty or invalid, the same elision logic is applied to printing
the default value.
When separating the constant offset from a GEP, if the pointer operand
is a constant ptradd (likely generated when we performed this transform
on that GEP), we accumulate the offset into the current offset. This
ensures that when there is a chain of GEPs the constant offset reaches
the final memory instruction where it can likely be folded into the
addressing.
Factor out most of the DIExpression docs from LangRef.rst into
SourceLevelDebugging.rst
What remains in LangRef is just enough context to make sense of how
DIExpression-as-metadata fits into the IR, including some examples of
the DIExpression syntax.
The rest now lives in the SourceLevelDebugging document, which gives
more context to make sense of DIExpression-as-semantic-entity.
Use sections to clearly separate DWARF opcodes from LLVM internal-only
opcodes, where before the distinction was only explicit in the source
code.
Also make some other changes like fixing typos, using :ref: rather than
unchecked links, and rewording DW_OP_LLVM_entry_value.
While debugging, I saw a log line of:
> Failed to resolve SDK path: Error while searching for SDK (XcodeSDK ''): Unrecognized SDK type:
Looking into how this might happen, it seems `ResolveSDKPathFromDebugInfo` appears to
(implicitly) assume there's at least one compile unit. This change adds a precondition
to return a meaningful error when there are no compile units.
Original: https://github.com/llvm/llvm-project/pull/146062
Currently it's hard to find the "general" options, since they are listed
in the middle of the "specific" options. Split them into two categories
so they are easier to find.
This can help in adding a potential new general option in a follow-up
patch.
Co-authored-by: Carlos Gálvez <carlos.galvez@zenseact.com>
This is required in hermetic testing downstream. It is not complete, and
will not work on hardware, however it runs on QEMU, and can report a
pass/fail on our tests.
The `sycl_kernel_entry_point` attribute only appertains to functions.
This change adds missing tests to validate that an appropriate
diagnostic is issued for likely unintentional application of the
attribute to a null declaration or a null statement; perhaps due to an
unintended semicolon.
In this patch:
1. Adapt the output of printDelinearization() to match what the script
expects to see, "Printing analysis 'Delinearization' for function".
2. Register the "Delinearization" pass in the update script.
3. Automatically remove the existing CHECK statements.
4. Update the tests with a run of:
```
$ ~/llvm-project/llvm/utils/update_analyze_test_checks.py
--opt=~/llvm-project/build/bin/opt
~/llvm-project/llvm/test/Analysis/Delinearization/*.ll
```
5. Drop llvm/test/Analysis/Delinearization/undef.ll because the test
does not pass the github-actions "undef deprecator."
6. Only run delinearization pretty-print pass on the most internal loop.
7. Only run delinearization pretty-print pass on load and store
instructions.
We can generate fpr->fpr instructions for G_SITOFP and G_UITOFP. It was
previously marking the instructions as FPR but then generating GPR
instructions and introducing a copy.
This pr implements the `remove-section` option for a `DXContainer`
object in `llvm-objcopy`.
It implements a base `removeParts` to the minimal `object`
representation of a `DXContainerObject`.
This is the second step to implement
https://github.com/llvm/llvm-project/issues/150275 as a compiler actions
that invokes llvm-objcopy for functionality.
The addition of v2f32 as a legal type, supported by the B64 register
class, has caused performance regressions, broken inline assembly, and
resulted in a couple (now fixed) mis-compilations. In order to mitigate
these issues, only mark this as a legal type when there exist operations
that support it, since for targets where this is not the case it serves
no purpose. To enable further debugging, add an option to disable v2f32.
In order to allow for a target-dependent set of legal types,
ComputePTXValueVTs has been fully re-written to take advantage of
TargetLowering call-lowering APIs.
We do not gain any additional security from having PIE on the test
binaries, and this does have an impact on test times. It is about 10%
from my measurements. Not as much as previous reports
(https://reviews.llvm.org/D140880), but still significant. This is a
similar gain to finish enabling the lit internal shell, which will take
significantly more effort. I also do not think this is a meaningful
enough difference from the "default" configuration to keep it the
default, especially given the option is mostly set by distros.
Originally commited in 362b9d78b4ee9107da2b5e90b3764b0f0fa610fe and then
reverted in cb63b75e32a415c9bfc298ed7fdcd67e8d9de54c.
This re-lands a subset of the changes to
dap_server.py/DebugCommunication and addresses the python3.10
compatibility issue.
This includes less type annotations since those were the reason for the
failures on that specific version of python.
I've done additional testing on python3.8, python3.10 and python3.13 to
further validate these changes.
Static analysis flagged these classes as having implemented the
destructor but not applying rule of three. This could lead to accidental
misuse and so it makes sense to apply it.
This patch adds a new set of randomized conformance tests for
single-precision bivariate math functions.
The functions included in this set were selected based on the following
criteria:
- An implementation exists in `libc/src/math/generic` (i.e., it is not
just a wrapper around a compiler built-in).
- The corresponding LLVM CPU libm implementation is correctly rounded.
- The function is listed in Table 65 of the OpenCL C Specification
v3.0.19.
- Add PermlaneSwapOp that lowers to `rocdl.permlane16.swap` and
`rocdl.permlane32.swap`
---------
Co-authored-by: Jakub Kuderski <kubakuderski@gmail.com>
This PR upstreams the GotoSolver pass.
It works by walking the function and matching each label to a goto. If a
label is not matched to a goto, it is removed and not lowered.
This patch fixes:
third-party/unittest/googletest/include/gtest/gtest.h:1379:11:
error: comparison of integers of different signs: 'const unsigned
long' and 'const int' [-Werror,-Wsign-compare]
Replace inttoptr (add (ptrtoint %B), %O) with (getelementptr i8, %B, %o)
if all users are ICmp instruction, which in turn means only the address
value is compared. We should be able to do this, if the src pointer,
the integer type and the destination pointer types have the same
bitwidth and address space.
A common source of such (inttoptr (add (ptrtoint %B), %O)) is from
various iterations in libc++.
In practice this triggers in a number of files in Clang and various open
source projects, including cppcheck, diamond, llama and more.
Alive2 Proof with constant offset: https://alive2.llvm.org/ce/z/K_5N_B
PR: https://github.com/llvm/llvm-project/pull/153421
Rename the pass `LinalgNamedOpConversionPass` to
`SimplifyDepthwiseConvPass` to avoid conflating it with the new
morphisms we are creating between the norms.
The default behaviour in DXC is to allow all extesions the compiler
knows about. We did the same in clang: all extensions that clang knows
about. However, this causes the shader to use different extensions
because the two compilers have different sets of extensions.
To avoid using a new extension when moving from DXC to Clang, we add the
special DXC suboptions to `-fspv-extension`. If `-fspv-extension=DXC` is
used, then the available extensions will be those available in DXC.
---------
Co-authored-by: Chris B <beanz@abolishcrlf.org>
We used to vectorize these scalably but after #147026 they were split
out from RecurKind::Add into their own RecurKinds, and we didn't mark
them as supported in isLegalToVectorizeReduction.
This caused the loop vectorizer to drop the scalable VPlan because it
thinks the reductions will be scalarized.
This fixes it by just marking them as supported.
Fixes#154554
These functions turned out to have the same bug that was in wcstok()
(fixed by 4fc9801), so add the missing tests and fix the code in a way
that matches wcstok().
Also fix incorrect test expectations in existing tests.
Also update the BUILD.bazel files to actually build the strsep() test.
The C++ standard requires stddef.h to declare all of its contents in the
global namespace. We were only doing it when trying to be compatible
with Microsoft extensions. Now we expose in C++11 or later, in addition
to exposing it in Microsoft extensions mode.
Fixes#154577
... builtins. We used to access the I'th index of the output vector, but
that doesn't work since the output vector is only half the size of the
input vector.
I tracked down the document which changed the way variables are handled
in for loops for C99, it was the same document that allowed mixing code
and declarations but the editor's report made it seem like the features
came from different papers.
This is an extension we backported to C89 but it's sufficiently distinct
in the tracking page so I've added it explicitly to the backported
features documentation.
Use `CRASHREPORTER_ANNOTATIONS_INITIALIZER` when possible, which will
handle the field initialization for us. That's what we already do in
compiler-rt:
0c480dd4b6/compiler-rt/lib/sanitizer_common/sanitizer_mac.cpp (L799-L817)
This way we won't get these warnings when the layout of
crashreporter_annotations_t changes:
```
llvm/lib/Support/PrettyStackTrace.cpp:92:65: warning: missing field 'blah' initializer [-Wmissing-field-initializers]
= { CRASHREPORTER_ANNOTATIONS_VERSION, 0, 0, 0, 0, 0, 0, 0 };
^
1 warning generated
```
This PR modifies the static_asserts checking the expected sizes in
__barrier_type.h, so that we can guarantee that our internal
implementation fits the public header.
The viewLikeOpInterface abstracts the behavior of an operation view one
buffer as another. However, the current interface only includes a
"getViewSource" method and lacks a "getViewDest" method.
Previously, it was generally assumed that viewLikeOpInterface operations
would have only one return value, which was the view dest. This
assumption was broken by memref.extract_strided_metadata, and more
operations may break these silent conventions in the future. Calling
"viewLikeInterface->getResult(0)" may lead to a core dump at runtime.
Therefore, we need 'getViewDest' method to standardize our behavior.
This patch adds the getViewDest function to viewLikeOpInterface and
modifies the usage points of viewLikeOpInterface to standardize its use.
Description
===========
OpenMP Tooling Interface Testing Library (ompTest) ompTest is a unit
testing framework for testing OpenMP implementations. It offers a
simple-to-use framework that allows a tester to check for OMPT events in
addition to regular unit testing code, supported by linking against
GoogleTest by default. It also facilitates writing concise tests while
bridging the semantic gap between the unit under test and the OMPT-event
testing.
Background
==========
This library has been developed to provide the means of testing OMPT
implementations with reasonable effort. Especially, asynchronous or
unordered events are supported and can be verified with ease, which may
prove to be challenging with LIT-based tests. Additionally, since the
assertions are part of the code being tested, ompTest can reference all
corresponding variables during assertion.
Basic Usage
===========
OMPT event assertions are placed before the code, which shall be tested.
These assertion can either be provided as one block or interleaved with
the test code. There are two types of asserters: (1) sequenced
"order-sensitive" and (2) set "unordered" assserters. Once the test is
being run, the corresponding events are triggered by the OpenMP runtime
and can be observed. Each of these observed events notifies asserters,
which then determine if the test should pass or fail.
Example (partial, interleaved)
==============================
```c++
int N = 100000;
int a[N];
int b[N];
OMPT_ASSERT_SEQUENCE(Target, TARGET, BEGIN, 0);
OMPT_ASSERT_SEQUENCE(TargetDataOp, ALLOC, N * sizeof(int)); // a ?
OMPT_ASSERT_SEQUENCE(TargetDataOp, H2D, N * sizeof(int), &a);
OMPT_ASSERT_SEQUENCE(TargetDataOp, ALLOC, N * sizeof(int)); // b ?
OMPT_ASSERT_SEQUENCE(TargetDataOp, H2D, N * sizeof(int), &b);
OMPT_ASSERT_SEQUENCE(TargetSubmit, 1);
OMPT_ASSERT_SEQUENCE(TargetDataOp, D2H, N * sizeof(int), nullptr, &b);
OMPT_ASSERT_SEQUENCE(TargetDataOp, D2H, N * sizeof(int), nullptr, &a);
OMPT_ASSERT_SEQUENCE(TargetDataOp, DELETE);
OMPT_ASSERT_SEQUENCE(TargetDataOp, DELETE);
OMPT_ASSERT_SEQUENCE(Target, TARGET, END, 0);
#pragma omp target parallel for
{
for (int j = 0; j < N; j++)
a[j] = b[j];
}
```
References
==========
This work has been presented at SC'24 workshops, see:
https://ieeexplore.ieee.org/document/10820689
Current State and Future Work
=============================
ompTest's development was mostly device-centric and aimed at OMPT device
callbacks and device-side tracing. Consequentially, a substantial part
of host-related events or features may not be supported in its current
state. However, we are confident that the related functionality can be
added and ompTest provides a general foundation for future OpenMP and
especially OMPT testing. This PR will allow us to upstream the
corresponding features, like OMPT device-side tracing in the future with
significantly reduced risk of introducing regressions in the process.
Build
=====
ompTest is linked against LLVM's GoogleTest by default, but can also be
built 'standalone'. Additionally, it comes with a set of unit tests,
which in turn require GoogleTest (overriding a standalone build). The
unit tests are added to the `check-openmp` target.
Use the following parameters to perform the corresponding build:
`LIBOMPTEST_BUILD_STANDALONE` (Default: ${OPENMP_STANDALONE_BUILD})
`LIBOMPTEST_BUILD_UNITTESTS` (Default: OFF)
---------
Co-authored-by: Jan-Patrick Lehr <JanPatrick.Lehr@amd.com>
Co-authored-by: Joachim <protze@rz.rwth-aachen.de>
That code is from a time when typeid pointers didn't exist. We can get
there for non-block, non-integral pointers, but we can't meaningfully
handle that case. Just return false.
Fixes#153712
Reverts llvm/llvm-project#153756
It leads to new build bot failure.
https://lab.llvm.org/buildbot/#/builders/145/builds/9200
```
BUILD FAILED: failed build (failure)
Step 5 (build-unified-tree) failure: build (failure) ...
254.983 [140/55/1504] Building CXX object tools/clang/tools/extra/clangd/tool/CMakeFiles/obj.clangdMain.dir/ClangdMain.cpp.o
FAILED: tools/clang/tools/extra/clangd/tool/CMakeFiles/obj.clangdMain.dir/ClangdMain.cpp.o
ccache /home/buildbots/llvm-external-buildbots/clang.19.1.7/bin/clang++ --gcc-toolchain=/gcc-toolchain/usr -DGTEST_HAS_RTTI=0 -D_DEBUG -D_GLIBCXX_ASSERTIONS -D_GNU_SOURCE -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -I/home/buildbots/llvm-external-buildbots/workers/ppc64le-clang-rhel-test/clang-ppc64le-rhel/build/tools/clang/tools/extra/clangd/tool -I/home/buildbots/llvm-external-buildbots/workers/ppc64le-clang-rhel-test/clang-ppc64le-rhel/llvm-project/clang-tools-extra/clangd/tool -I/home/buildbots/llvm-external-buildbots/workers/ppc64le-clang-rhel-test/clang-ppc64le-rhel/llvm-project/clang-tools-extra/clangd/../include-cleaner/include -I/home/buildbots/llvm-external-buildbots/workers/ppc64le-clang-rhel-test/clang-ppc64le-rhel/build/tools/clang/tools/extra/clangd/../clang-tidy -I/home/buildbots/llvm-external-buildbots/workers/ppc64le-clang-rhel-test/clang-ppc64le-rhel/llvm-project/clang/include -I/home/buildbots/llvm-external-buildbots/workers/ppc64le-clang-
rhel-test/clang-ppc64le-rhel/build/tools/clang/include -I/home/buildbots/llvm-external-buildbots/workers/ppc64le-clang-rhel-test/clang-ppc64le-rhel/build/include -I/home/buildbots/llvm-external-buildbots/workers/ppc64le-clang-rhel-test/clang-ppc64le-rhel/llvm-project/llvm/include -I/home/buildbots/llvm-external-buildbots/workers/ppc64le-clang-rhel-test/clang-ppc64le-rhel/llvm-project/clang-tools-extra/clangd -I/home/buildbots/llvm-external-buildbots/workers/ppc64le-clang-rhel-test/clang-ppc64le-rhel/build/tools/clang/tools/extra/clangd -fPIC -fno-semantic-interposition -fvisibility-inlines-hidden -Werror -Werror=date-time -Werror=unguarded-availability-new -Wall -Wextra -Wno-unused-parameter -Wwrite-strings -Wcast-qual -Wmissing-field-initializers -pedantic -Wno-long-long -Wc++98-compat-extra-semi -Wimplicit-fallthrough -Wcovered-switch-default -Wno-noexcept-type -Wnon-virtual-dtor -Wdelete-non-virtual-dtor -Wsuggest-override -Wstring-conversion -Wmisleading-indentation -Wctad-maybe -unsupported -fdiagnostics-color -ffunction-sections -fdata-sections -fno-common -Woverloaded-virtual -Wno-nested-anon-types -O3 -DNDEBUG -std=c++17 -fno-exceptions -funwind-tables -fno-rtti -UNDEBUG -MD -MT tools/clang/tools/extra/clangd/tool/CMakeFiles/obj.clangdMain.dir/ClangdMain.cpp.o -MF tools/clang/tools/extra/clangd/tool/CMakeFiles/obj.clangdMain.dir/ClangdMain.cpp.o.d -o tools/clang/tools/extra/clangd/tool/CMakeFiles/obj.clangdMain.dir/ClangdMain.cpp.o -c /home/buildbots/llvm-external-buildbots/workers/ppc64le-clang-rhel-test/clang-ppc64le-rhel/llvm-project/clang-tools-extra/clangd/tool/ClangdMain.cpp
In file included from /home/buildbots/llvm-external-buildbots/workers/ppc64le-clang-rhel-test/clang-ppc64le-rhel/llvm-project/clang-tools-extra/clangd/tool/ClangdMain.cpp:10:
In file included from /home/buildbots/llvm-external-buildbots/workers/ppc64le-clang-rhel-test/clang-ppc64le-rhel/llvm-project/clang-tools-extra/clangd/ClangdLSPServer.h:12:
In file included from /home/buildbots/llvm-external-buildbots/workers/ppc64le-clang-rhel-test/clang-ppc64le-rhel/llvm-project/clang-tools-extra/clangd/ClangdServer.h:12:
In file included from /home/buildbots/llvm-external-buildbots/workers/ppc64le-clang-rhel-test/clang-ppc64le-rhel/llvm-project/clang-tools-extra/clangd/CodeComplete.h:18:
In file included from /home/buildbots/llvm-external-buildbots/workers/ppc64le-clang-rhel-test/clang-ppc64le-rhel/llvm-project/clang-tools-extra/clangd/ASTSignals.h:12:
In file included from /home/buildbots/llvm-external-buildbots/workers/ppc64le-clang-rhel-test/clang-ppc64le-rhel/llvm-project/clang-tools-extra/clangd/ParsedAST.h:23:
In file included from /home/buildbots/llvm-external-buildbots/workers/ppc64le-clang-rhel-test/clang-ppc64le-rhel/llvm-project/clang-tools-extra/clangd/CollectMacros.h:12:
In file included from /home/buildbots/llvm-external-buildbots/workers/ppc64le-clang-rhel-test/clang-ppc64le-rhel/llvm-project/clang-tools-extra/clangd/Protocol.h:26:
In file included from /home/buildbots/llvm-external-buildbots/workers/ppc64le-clang-rhel-test/clang-ppc64le-rhel/llvm-project/clang-tools-extra/clangd/URI.h:14:
/home/buildbots/llvm-external-buildbots/workers/ppc64le-clang-rhel-test/clang-ppc64le-rhel/llvm-project/llvm/include/llvm/Support/Registry.h:110:47: error: instantiation of variable 'llvm::Registry<clang::clangd::FeatureModule>::Head' required here, but no definition is available [-Werror,-Wundefined-var-template]
110 | static iterator begin() { return iterator(Head); }
| ^
/home/buildbots/llvm-external-buildbots/workers/ppc64le-clang-rhel-test/clang-ppc64le-rhel/llvm-project/llvm/include/llvm/Support/Registry.h:114:25: note: in instantiation of member function 'llvm::Registry<clang::clangd::FeatureModule>::begin' requested here
114 | return make_range(begin(), end());
| ^
/home/buildbots/llvm-external-buildbots/workers/ppc64le-clang-rhel-test/clang-ppc64le-rhel/llvm-project/clang-tools-extra/clangd/tool/ClangdMain.cpp:1021:64: note: in instantiation of member function 'llvm::Registry<clang::clangd::FeatureModule>::entries' requested here
1021 | for (FeatureModuleRegistry::entry E : FeatureModuleRegistry::entries()) {
| ^
/home/buildbots/llvm-external-buildbots/workers/ppc64le-clang-rhel-test/clang-ppc64le-rhel/llvm-project/llvm/include/llvm/Support/Registry.h:61:18: note: forward declaration of template entity is here
61 | static node *Head;
| ^
/home/buildbots/llvm-external-buildbots/workers/ppc64le-clang-rhel-test/clang-ppc64le-rhel/llvm-project/llvm/include/llvm/Support/Registry.h:110:47: note: add an explicit instantiation declaration to suppress this warning if 'llvm::Registry<clang::clangd::FeatureModule>::Head' is explicitly instantiated in another translation unit
110 | static iterator begin() { return iterator(Head); }
| ^
1 error generated.
```
I need some time to fix this in a correct way
If we have entries in Def2LaneDefs, we always have to use it. Move the
check before.
Otherwise we may not pick the correct operand, e.g. if Op was a
replicate recipe that got single-scalar after replicating it.
Fixes https://github.com/llvm/llvm-project/issues/154330.
The cost model previously overestimating throughput costs to wide
fixed-length saturating arithmetic intrinsics when using SVE with a
fixed vscale of 2. These costs ended up much higher than for the same
operations using NEON, despite being fully legal and efficient with SVE.
This patch adjusts the cost model to avoid penalising these intrinsics
under SVE.
This patch adds a -r|--relative-paths option to llvm-lit, which when
enabled will print test case names using paths relative to the current
working directory. The legacy default without that option is that test
cases are identified using a path relative to the test suite.
Only the summary report is impacted. That normally include failed tests,
unless unless options such as --show-pass.
Background to this patch was the discussion here
https://discourse.llvm.org/t/test-case-paths-in-llvm-lit-output-are-lacking-the-location-of-the-test-dir-itself/87973
with a goal to making it easier to copy-n-paste the path to the failing
test cases.
Examples showing difference in "Passed Tests" and "Failed Tests":
> llvm-lit --show-pass test/Transforms/Foo
PASS: LLVM :: Transforms/Foo/test1.txt (1 of 2)
FAIL: LLVM :: Transforms/Foo/test2.txt (2 of 2)
Passed Tests (1):
LLVM :: Transforms/Foo/test1.txt
Failed Tests (1):
LLVM :: Transforms/Foo/test2.txt
> llvm-lit --show-pass --relative-paths test/Transforms/Foo
PASS: LLVM :: Transforms/Foo/test1.txt (1 of 2)
FAIL: LLVM :: Transforms/Foo/test2.txt (2 of 2)
Passed Tests (1):
test/Transforms/Foo/test1.txt
Failed Tests (1):
test/Transforms/Foo/test2.txt
`replaceAllUsesWith` is not safe to use in a dialect conversion and will
be deactivated soon (#154112). Fix commit fixes some API violations.
Also some general improvements.
When an instruction that the disassembler does not recognize is in an IT
block, we should still advance the IT state otherwise the IT state
spills over into the next recognized instruction, which is incorrect.
We want to avoid disassembly like:
it eq
<unknown> // Often because disassembler has insufficient target info.
addeq r0,r0,r0 // eq spills over into add.
Fixes#150569
It was previously failing because of a warning marking a C++20 feature
as an extension.
This is a follow-up to 85043c1c146fd5658ad4c5b5138e58994333e645 that
introduced the test.
The vector granule (AArch64 DWARF register 46) is a pseudo-register that
contains the available size in bits of SVE vector registers in the
current call frame, divided by 64. The vector granule can be used in
DWARF expressions to describe SVE/SME stack frame layouts (e.g., the
location of SVE callee-saves).
The first time VG is evaluated (if not already set), it is initialized
to the result of evaluating a "CNTD" instruction (this assumes SVE is
available).
To support SME, the value of VG can change per call frame; this is
currently handled like any other callee-save and is intended to support
the unwind information implemented in #152283. This limits how VG is
used in the CFI information of functions with "streaming-mode changes"
(mode changes that change the SVE vector length), to make the unwinder's
job easier.
The orc-rt extensible RTTI mechanism is used to provide simple dynamic RTTI
checks for orc-rt types that do not depend on standard C++ RTTI (meaning that
they will work equally well for programs compiled with -fno-rtti).
ORC_RT_MARK_AS_BITMASK_ENUM and ORC_RT_DECLARE_ENUM_AS_BITMASK can be used to
easily add support for bitmask operators (&, |, ^, ~) to enum types.
This code was derived from LLVM's include/llvm/ADT/BitmaskEnum.h header.
It is generally better to allow the target independent combines before
creating AArch64 specific nodes (providing they don't mess it up). This
moves the generation of BSL nodes to lowering, not a combine, so that
intermediate nodes are more likely to be optimized. There is a small
change in the constant handling to detect legalized buildvector
arguments correctly.
Fixes#149380 but not directly. #151856 contained a direct fix for
expanding the pseudos.
The simplest way is:
1. Save `vtype` to a scalar register.
2. Insert a `vsetvli`.
3. Use segment load/store.
4. Restore `vtype` via `vsetvl`.
But `vsetvl` is usually slow, so this PR is not in this way.
Instead, we use wider whole load/store instructions if the register
encoding is aligned. We have done the same optimization for COPY in
https://github.com/llvm/llvm-project/pull/84455.
We found this suboptimal implementation when porting some video codec
kernels via RVV intrinsics.
The order entries in the tablegen API files are iterated is not the
order
they appear in the file. To avoid any issues with the order changing
in future, we now generate all definitions of a certain class before
class that can use them.
This is a NFC; the definitions don't actually change, just the order
they exist in in the OffloadAPI.h header.
This keeps it closer to the other legality checks like the FP exceptions
check.
It also means that isSupportedInstr only needs to check the opcode,
which allows it to be replaced with a TSFlags based check in a later
patch.
This patch works towards consolidating all Clang debug-info into the
`clang/test/DebugInfo` directory
(https://discourse.llvm.org/t/clang-test-location-of-clang-debug-info-tests/87958).
Here we move only the `clang/test/CodeGenCXX` tests. I created a `CXX`
subdirectory for now because many of the tests I checked actually did
seem C++-specific. There is probably overlap between the `Generic` and
`CXX` subdirectory, but I haven't gone through and audited them all.
The list of files i came up with is:
1. searched for anything with `*debug-info*` in the filename
2. searched for occurrences of `debug-info-kind` in the tests
There's a couple of tests in `clang/test/CodeGenCXX` that still set
`-debug-info-kind`. They probably don't need to do that, but I'm not
changing that as part of this PR.
This patch adds feature modules registry, as discussed with @kadircet in
[discourse](https://discourse.llvm.org/t/rfc-registry-for-feature-modules/87733).
Feature modules, which added into the feature module set from registry
entries, can't expose public API, but still can be used via
`FeatureModule` interface.
MSVC's STL marks `std::make_shared`, `std::allocate_shared`,
`std::bitset::to_ulong`, and `std::bitset::to_ullong` as
`[[nodiscard]]`, which causes these libcxx tests to emit righteous
warnings. They should use the traditional `(void)` cast technique to
ignore the return values.
Currently, Flang can generate no-loop kernels for all OpenMP target
kernels in the program if the flags
-fopenmp-assume-teams-oversubscription or
-fopenmp-assume-threads-oversubscription are set.
If we add an additional parameter, we can choose
in the future which OpenMP kernels should be generated as no-loop
kernels.
This PR doesn't modify current behavior of oversubscription flags.
RFC for no-loop kernels:
https://discourse.llvm.org/t/rfc-no-loop-mode-for-openmp-gpu-kernels/87517
The change in PR #154268 introduced a dependency on the `__GLIBC_PREREQ`
macro, which is not defined in musl libc. This caused the build to fail
in environments using musl.
This patch fixes the build by including
`sanitizer_common/sanitizer_glibc_version.h`. This header provides a
fallback definition for `__GLIBC_PREREQ` when LLVM is built against
non-glibc C libraries, resolving the compilation error.
It is going to grow, so it makes sense to move its definition
out of class. Instead, inline `populateInstruction()` into it.
Also, rename a couple of methods to better convey their meaning.
That is, on all targets except ARM and AArch64.
This field used to be required due to a bug, it was fixed long ago
by 23423c0ea8d414e56081cb6a13bd8b2cc91513a9.
This patch contains a list of tests that are currently failing in the
LLVM_ENABLE_PROFCHECK=ON build. This enables passing them to lit through
the LIT_XFAIL env variable. This is necessary for getting a buildbot
spun up to catch regressions while work is being done to fix the
existing issues.
We need to keep this in the LLVM tree so that tests can be removed from
the list at the same time the passes causing issues are fixed.
Issue #147390
LSan was recently refactored to call GetMaxUserVirtualAddress for
diagnostic purposes. This leads to failures for some of our downstream
tests which only run with lsan. This occurs because
GetMaxUserVirtualAddress depends on setting up shadow via a call to
__sanitizer_shadow_bounds, but shadow bounds aren't set for standalone
lsan because it doesn't use shadow. This updates the function to invoke
the same syscall used by __sanitizer_shadow_bounds calls for getting the
memory limit. Ideally this function would only be called once since we
only need to get the bounds once.
More context in https://fxbug.dev/437346226.
Operate directly on the existing Ops vector instead of copying to
a new vector. This is similar to what the autogenerated codegen
does for other intrinsics.
Currently only cases rooted at a full copy of an MFMA result are
handled.
Prepare to relax that by testing more intricate subregister usage.
Currently only full copies are handled, add some tests to help work
towards handling subregisters.
Previously it would just assert if the extract needed elements from
both halves. Extract the individual elements from both halves and
create a new vector, as the simplest implementation. This could
try to do better and create a partial extract or shuffle (or
maybe that's best left for the combiner to figure out later).
Fixes secondary issue noticed as part of #153808
`VPEVLBasedIVPHIRecipe` will lower to VPInstruction scalar phi and
generate scalar phi. This recipe will only occupy a scalar register just
like other phi recipes.
This patch fix the register usage for `VPEVLBasedIVPHIRecipe` from
vector
to scalar which is close to generated vector IR.
https://godbolt.org/z/6Mzd6W6ha shows that no register spills when
choosing `<vscale x 16>`.
Note that this test is basically copied from AArch64.
SimplifyBranchConditionForVFAndUF only recognized canonical IVs and a
few PHI
recipes in the loop header. With more IV-step optimizations,
the canonical widen-canonical-iv can be replaced by a canonical
VPWidenIntOrFpInduction,
which the pass did not handle, causing regressions (missed
simplifications).
This patch replaces canonical VPWidenIntOrFpInduction with a StepVector
in the vector preheader
since the vector loop region only executes once.
I'm trying to remove the redirection in SmallSet.h:
template <typename PointeeType, unsigned N>
class SmallSet<PointeeType*, N> : public SmallPtrSet<PointeeType*, N>
{};
to make it clear that we are using SmallPtrSet. There are only
handful places that rely on this redirection.
This patch replaces SmallSet to SmallPtrSet where the element type is
a pointer.
I'm trying to remove the redirection in SmallSet.h:
template <typename PointeeType, unsigned N>
class SmallSet<PointeeType*, N> : public SmallPtrSet<PointeeType*, N>
{};
to make it clear that we are using SmallPtrSet. There are only
handful places that rely on this redirection.
This patch replaces SmallSet to SmallPtrSet where the element type is
a pointer.
I'm trying to remove the redirection in SmallSet.h:
template <typename PointeeType, unsigned N>
class SmallSet<PointeeType*, N> : public SmallPtrSet<PointeeType*, N>
{};
to make it clear that we are using SmallPtrSet. There are only
handful places that rely on this redirection.
This patch replaces SmallSet to SmallPtrSet where the element type is
a pointer.
#153975 added a new test,
`test/CodeGen/AMDGPU/disable-preload-kernargs.ll`, that triggers an
assertion under `LLVM_ENABLE_EXPENSIVE_CHECKS` complaining about not
invalidating analyses even when the Pass made changes. It was caused by
the fact that the Pass only invalidates the analyses when number of
explicit arguments is greater than zero, while it is possible that some
functions will be removed even when there isn't any explicit argument,
hence the missed invalidation.
If src2 and dst aren't the same register, to fold a copy
to AGPR into the instruction we also need to reassign src2
to an available AGPR. All the other uses of src2 also need
to be compatible with the AGPR replacement in order to avoid
inserting other copies somewhere else.
Perform this transform, after verifying all other uses are
compatible with AGPR, and have an available AGPR available at
all points (which effectively means rewriting a full chain of
mfmas and load/store at once).
Currently the privatization recipe of a scalar allocatable is as follow:
```
acc.private.recipe @privatization_ref_box_heap_i32 : !fir.ref<!fir.box<!fir.heap<i32>>> init {
^bb0(%arg0: !fir.ref<!fir.box<!fir.heap<i32>>>):
%0 = fir.alloca !fir.box<!fir.heap<i32>>
%1:2 = hlfir.declare %0 {uniq_name = "acc.private.init"} : (!fir.ref<!fir.box<!fir.heap<i32>>>) -> (!fir.ref<!fir.box<!fir.heap<i32>>>, !fir.ref<!fir.box<!fir.heap<i32>>>)
acc.yield %1#0 : !fir.ref<!fir.box<!fir.heap<i32>>>
}
```
This change adds the allocation for the scalar.
Summary:
This patch changes the linux build to use the wide reads on the memory
operations by default. These memory functions will now potentially read
outside of the bounds explicitly allowed by the current function. While
technically undefined behavior in the standard, plenty of C library
implementations do this. it will not cause a segmentation fault on linux
as long as you do not cross a page boundary, and because we are only
*reading* memory it should not have atomic effects.
Operate directly on the existing Ops vector instead of copying to
a new vector. This is similar to what the autogenerated codegen
does for other intrinsics.
This reduced the clang binary size by ~96kb on my local Release+Asserts
build.
We used to abuse Operands list to store instruction encoding's
DecoderMethod there. Let's store it in the InstructionEncoding class
instead, where it belongs.
`ASTReader::FinishedDeserializing()` calls
`adjustDeductedFunctionResultType(...)` [0], which in turn calls
`FunctionDecl::getMostRecentDecl()`[1]. In modules builds,
`getMostRecentDecl()` may reach out to the `ASTReader` and start
deserializing again. Starting deserialization starts `ReadTimer`;
however, `FinishedDeserializing()` doesn't call `stopTimer()` until
after it's call to `adjustDeductedFunctionResultType(...)` [2]. As a
result, we hit an assert checking that we don't start an already started
timer [3]. To fix this, we simply don't start the timer if it's already
running.
Unfortunately I don't have a test case for this yet as modules builds
are notoriously difficult to reduce.
[0]:
4d2288d318/clang/lib/Serialization/ASTReader.cpp (L11053)
[1]:
4d2288d318/clang/lib/AST/ASTContext.cpp (L3804)
[2]:
4d2288d318/clang/lib/Serialization/ASTReader.cpp (L11065-L11066)
[3]:
4d2288d318/llvm/lib/Support/Timer.cpp (L150)
ActionCache is used to store a mapping from CASID to CASID. The current
implementation of the ActionCache can only be used to associate the
key/value from the same hash context.
ActionCache has two operations: `put` to store the key/value and `get`
to
lookup the key/value mapping. ActionCache uses the same TrieRawHashMap
data structure to store the mapping, where is CASID of the key is the
hash to index the map.
While CASIDs for key/value are often associcate with actual CAS
ObjectStore, it doesn't provide the guarantee of the existence of such
object in any ObjectStore.
When providing allocation and deallocation traces,
the ASan compiler-rt runtime already provides call
addresses (`TracePCType::Calls`).
On Darwin, system sanitizers (libsanitizers)
provides return address. It also discards a few
non-user frames at the top of the stack, because
these internal libmalloc/libsanitizers stack
frames do not provide any value when diagnosing
memory errors.
Introduce and add handling for
`TracePCType::ReturnsNoZerothFrame` to cover this
case and enable libsanitizers traces line-level
testing.
rdar://157596927
---
Commit 1 is a mechanical refactoring to introduce
and adopt `TracePCType` enum to replace
`pcs_are_call_addresses` bool. It preserve the
current behavior:
```
pcs_are_call_addresses:
false -> TracePCType::Returns (default)
true -> TracePCType::Calls
```
Best reviewed commit by commit.
Prevent an assertion failure in the cstring checker when library
functions like memcpy are defined with non-default address spaces.
Adds a test for this case.
The previous implementation of getExactInverse used the following check
to identify powers of two:
// Check that the number is a power of two by making sure that only the
// integer bit is set in the significand.
if (significandLSB() != semantics->precision - 1)
return false;
This condition verifies that the only set bit in the significand is the
integer bit, which is correct for normal numbers. However, this logic is
not correct for subnormal values.
APFloat represents subnormal numbers by shifting the significand right
while holding the exponent at its minimum value. For a power of two in
the subnormal range, its single set bit will therefore be at a position
lower than precision - 1. The original check would consequently fail,
causing the function to determine that these numbers do not have an
exact multiplicative inverse.
The new logic calculated this correctly but it seems that
test/CodeGen/Thumb2/mve-vcvt-fixed-to-float.ll expected the old
behavior.
Seeing as how getExactInverse does not have tests or documentation, we
conservatively maintain (and document) this behavior.
This reverts commit 47e62e846beb267aad50eb9195dfd855e160483e.
Adds the `#llvm.target<triple = $TRIPLE, chip = $CHIP, features =
$FEATURES>` attribute and along with a `-llvm-target-to-data-layout`
pass to derive a MLIR data layout from the LLVM data layout string
(using the existing `DataLayoutImporter`). The attribute implements the
relevant DLTI-interfaces, to expose the `triple`, `chip` (AKA `cpu`) and
`features` on `#llvm.target` and the full `DataLayoutSpecInterface`. The
pass combines the generated `#dlti.dl_spec` with an existing `dl_spec`
in case one is already present, e.g. a `dl_spec` which is there to
specify size of the `index` type.
Adds a `TargetAttrInterface` which can be implemented by all attributes
representing LLVM targets.
Similar to the Draft PR https://github.com/llvm/llvm-project/pull/78073.
RFC on which this PR is based:
https://discourse.llvm.org/t/mandatory-data-layout-in-the-llvm-dialect/85875
Static analysis flagged the columns - 1 code, it was correct but the
assumption was not obvious. I document the assumption w/ assertions.
While digging through related code I found getColumnNumber that looks
wrong at first inspection and adding parentheses makes it clearer.
Goal is simply to reduce direct usage of getLength and setLength so that
if we end up moving memset.pattern (whose length is in elements) there
are fewer places to audit.
Given the test case:
```llvm
define fastcc i16 @testbtst(i16 %a) nounwind {
entry:
switch i16 %a, label %no [
i16 11, label %yes
i16 10, label %yes
i16 9, label %yes
i16 4, label %yes
i16 3, label %yes
i16 2, label %yes
]
yes:
ret i16 1
no:
ret i16 0
}
```
We currently get this result:
```asm
testbtst: ; @testbtst
; %bb.0: ; %entry
move.l %d0, %d1
and.l #65535, %d1
sub.l #11, %d1
bhi .LBB0_3
; %bb.1: ; %entry
and.l #65535, %d0
move.l #3612, %d1
btst %d0, %d1
bne .LBB0_3 ; <------- Erroneous condition
; %bb.2: ; %yes
moveq #1, %d0
rts
.LBB0_3: ; %no
moveq #0, %d0
rts
```
The cause of this is a line that explicitly reverses the `btst`
condition code. But on M68k, `btst` sets condition codes the same as
`and` with a bitmask, meaning `EQ` indicates failure (bit is zero) and
not success, so the condition does not need to be reversed.
In my testing, I've only been able to get switch statements to lower to
`btst`, so I wasn't able to explicitly test other options for lowering.
But (if possible to trigger) I believe they have the same logical error.
For example, in `LowerAndToBTST()`, a comment specifies that it's
lowering a case where the `and` result is compared against zero, which
means the corresponding `btst` condition should also not be reversed.
This patch simply flips the ternary expression in
`getBitTestCondition()` to match the ISD condition code with the same
M68k code, instead of the opposite.
Remove the ArrayRef<const Value*> Args operand from
getOperandsScalarizationOverhead and require that the callers
de-duplicate arguments and filter constant operands.
Removing the Value * based Args argument enables callers where no Value
* operands are available to use the function in a follow-up: computing
the scalarization cost directly for a VPlan recipe.
It also allows more accurate cost-estimates in the future: for example,
when vectorizing a loop, we could also skip operands that are live-ins,
as those also do not require scalarization.
PR: https://github.com/llvm/llvm-project/pull/154126
When building the base type for constructor initializer, the case of an
UnresolvedUsingType was not being handled.
For the non-dependent case, we are also skipping adding the UsingType,
but this is just missing information in the AST. A FIXME for this is
added.
This fixes a regression introduced in #147835, which was never released,
so there are no release notes.
Fixes#154436
This patch implements the `RandomGenerator`, a new input generator that
enables conformance testing for functions with large input spaces (e.g.,
double-precision math functions).
**Architectural Refactoring**
To support different generation strategies in a clean and extensible
way, the existing `ExhaustiveGenerator` was refactored into a new class
hierarchy:
* A new abstract base class, `RangeBasedGenerator`, was introduced using
the Curiously Recurring Template Pattern (CRTP). It contains the common
logic for generators that operate on a sequence of ranges.
* `ExhaustiveGenerator` now inherits from this base class, simplifying
its implementation.
**New Components**
* The new `RandomGenerator` class also inherits from
`RangeBasedGenerator`. It implements a strategy that randomly samples a
specified number of points from the total input space.
* Random number generation is handled by a new, self-contained
`RandomState` class (a `xorshift64*` PRNG seeded with `splitmix64`) to
ensure deterministic and reproducible random streams for testing.
**Example Usage**
As a first use case and demonstration of this new capability, this patch
also adds the first double-precision conformance test for the `log`
function. This test uses the new `RandomGenerator` to validate the
implementations from the `llvm-libm`, `cuda-math`, and `hip-math`
providers.
Summary:
Clang has support for boolean vectors, these builtins expose the LLVM
instruction of the same name. This differs from a manual load and select
by potentially suppressing traps from deactivated lanes.
Fixes: https://github.com/llvm/llvm-project/issues/107753
Summary:
We added boolean vectors in clang 15 and wish to extend them further in
clang-22. However, there's no way to query for their support as they are
separate to the normal extended vector type. This adds a feature so we
can check for it as a feature directly.
This pr implements the boiler plate required to use `llvm-objcopy` for
`DXContainer` object files.
It defines a minimal structure `object` to represent the `DXContainer`
header and the following parts.
This structure is a simple representation of the object data to allow
for simple modifications at the granularity of each part. It follows
similarily to how the respective `object`s are defined for `ELF`,
`wasm`, `XCOFF`, etc.
This is the first step to implement
https://github.com/llvm/llvm-project/issues/150275 and
https://github.com/llvm/llvm-project/issues/150277 as compiler actions
that invoke `llvm-objcopy` for functionality.
Add `mlir-capi-global-constructors-test` to `MLIR_TEST_DEPENDS` when
`MLIR_ENABLE_EXECUTION_ENGINE` is enabled, to ensure that it is also
built during standalone builds, and therefore fix test failure due to
the executable being missing.
I don't understand the purpose of `LLVM_ENABLE_PIC AND TARGET
${LLVM_NATIVE_ARCH}` block, but the condition is not true in standalone
builds.
Fixes 7610b1372955da55e3dc4e2eb1440f0304a56ac8.
`GetOmpObjectList` takes a clause, and returns the pointer to the
contained OmpObjectList, or nullptr if the clause does not contain one.
Some clauses with object list were not recognized: handle all clauses,
and move the implementation to flang/Parser/openmp-utils.cpp.
This PR adds support for complex power operations (`cpow`) in the
`ComplexToROCDLLibraryCalls` conversion pass, specifically targeting
AMDGPU architectures. The implementation optimises complex
exponentiation by using mathematical identities and special-case
handling for small integer powers.
- Force lowering to `complex.pow` operations for the `amdgcn-amd-amdhsa`
target instead of using library calls
- Convert `complex.pow(z, w)` to `complex.exp(w * complex.log(z))` using
mathematical identity
A CMake change included in CMake 4.0 makes `AIX` into a variable
(similar to `APPLE`, etc.)
ff03db6657
However, `${CMAKE_SYSTEM_NAME}` unfortunately also expands exactly to
`AIX` and `if` auto-expands variable names in CMake. That means you get
a double expansion if you write:
`if (${CMAKE_SYSTEM_NAME} MATCHES "AIX")`
which becomes:
`if (AIX MATCHES "AIX")`
which is as if you wrote:
`if (ON MATCHES "AIX")`
You can prevent this by quoting the expansion of "${CMAKE_SYSTEM_NAME}",
due to policy
[CMP0054](https://cmake.org/cmake/help/latest/policy/CMP0054.html#policy:CMP0054)
which is on by default in 4.0+. Most of the LLVM CMake already does
this, but this PR fixes the remaining cases where we do not.
This patch is part of the upstreaming effort for supporting SYCL
language front end.
It makes the following changes:
1. Adds sycl_external attribute for functions with external linkage,
which is intended for use to implement the SYCL_EXTERNAL macro as
specified by the SYCL 2020 specification
2. Adds checks to avoid emitting device code when sycl_external and
sycl_kernel_entry_point attributes are not enabled
3. Fixes test failures caused by the above changes
This patch is missing diagnostics for the following diagnostics listed
in the SYCL 2020 specification's section 5.10.1, which will be addressed
in a subsequent PR:
Functions that are declared using SYCL_EXTERNAL have the following
additional restrictions beyond those imposed on other device functions:
1. If the SYCL backend does not support the generic address space then
the function cannot use raw pointers as parameter or return types.
Explicit pointer classes must be used instead;
2. The function cannot call group::parallel_for_work_item;
3. The function cannot be called from a parallel_for_work_group scope.
In addition to that, the subsequent PR will also implement diagnostics
for inline functions including virtual functions defined as inline.
---------
Co-authored-by: Mariya Podchishchaeva <mariya.podchishchaeva@intel.com>
The new builtin `__builtin_dedup_pack` removes duplicates from list of
types.
The added builtin is special in that they produce an unexpanded pack
in the spirit of P3115R0 proposal.
Produced packs can be used directly in template argument lists and get
immediately expanded as soon as results of the computation are
available.
It allows to easily combine them, e.g.:
```cpp
template <class ...T>
struct Normalize {
// Note: sort is not included in this PR, it illustrates the idea.
using result = std::tuple<
__builtin_sort_pack<
__builtin_dedup_pack<int, double, T...>...
>...>;
}
;
```
Limitations:
- only supported in template arguments and bases,
- can only be used inside the templates, even if non-dependent,
- the builtins cannot be assigned to template template parameters.
The actual implementation proceeds as follows:
- When the compiler encounters a `__builtin_dedup_pack` or other
type-producing
builtin with dependent arguments, it creates a dependent
`TemplateSpecializationType`.
- During substitution, if the template arguments are non-dependent, we
will produce: a new type `SubstBuiltinTemplatePackType`, which stores
an argument pack that needs to be substituted. This type is similar to
the existing `SubstTemplateParmPack` in that it carries the argument
pack that needs to be expanded further. The relevant code is shared.
- On top of that, Clang also wraps the resulting type into
`TemplateSpecializationType`, but this time only as a sugar.
- To actually expand those packs, we collect the produced
`SubstBuiltinTemplatePackType` inside `CollectUnexpandedPacks`.
Because we know the size of the produces packs only after the initial
substitution, places that do the actual expansion will need to have a
second run over the substituted type to finalize the expansions (in
this patch we only support this for template arguments, see
`ExpandTemplateArgument`).
If the expansion are requested in the places we do not currently
support, we will produce an error.
More follow-up work will be needed to fully shape this:
- adding the builtin that sorts types,
- remove the restrictions for expansions,
- implementing P3115R0 (scheduled for C++29, see
https://github.com/cplusplus/papers/issues/2300).
This function tries to look for (seteq (and (reduce_or), mask), 0). If
the mask is a sign bit, InstCombine will have turned it into (setgt
(reduce_or), -1). We should handle that case too.
I'm looking into adding the same canonicalization to SimplifySetCC and
this change is needed to prevent test regressions.
Blocks without a terminator are not handled correctly by
`Block::without_terminator`: the last operation is excluded, even when
it is not a terminator. With this commit, only terminators are excluded.
If the last operation is unregistered, it is included for safety.
Transfer all casts by kind as we currently do implicit casts. This
obviates the need for specific handling of static casts.
Also transfer CK_BaseToDerived and CK_DerivedToBase and add tests for
these and missing tests for already-handled cast types.
Ensure that CK_BaseToDerived casts result in modeling of the fields of the derived class.
When either one of the operands is all ones in high or low parts,
splitting these opens up other opportunities for combines. One of two
new instructions will either be removed or become a simple copy.
Add parameter to file lock API to allow exclusive file lock. Both Unix
and Windows support lock the file exclusively for write for one process
and LLVM OnDiskCAS uses exclusive file lock to coordinate CAS creation.
I have seen misuse of the `hasEffect` API in downstream projects: users
sometimes think that `hasEffect == false` indicates that the operation
does not have a certain memory effect. That's not necessarily the case.
When the op does not implement the `MemoryEffectsOpInterface`, it is
unknown whether it has the specified effect. "false" can also mean
"maybe".
This commit clarifies the semantics in the documentation. Also adds
`hasUnknownEffects` and `mightHaveEffect` convenience functions. Also
simplifies a few call sites.
These invariants are always expected to hold, however it's not always
clear that they do. Adding explicit checks for these invariants inside
non-trivial functions of basic_streambuf makes that clear.
A number of recipes compute costs for the same opcodes for scalars or
vectors, depending on the recipe.
Move the common logic out to a helper in VPRecipeWithIRFlags, that is
then used by VPReplicateRecipe, VPWidenRecipe and VPInstruction.
This makes it easier to cover all relevant opcodes, without duplication.
PR: https://github.com/llvm/llvm-project/pull/153361
The standard is ambiguous, but we can only support
arrays/array-sections/etc of the composite type, so make sure we enforce
the rule that way. This will better support how we need to do lowering.
Enable gfx942 for tests that are affected by the an AMDGPU bitcast
constant combine (#154115)
Expecting to see more tests affected in aforementioned PR after rebase
on top of this PR
recreate this patch from
https://github.com/llvm/llvm-project/pull/153894
It seems ISel sliently ignore the `i64 = zext i16` with a chained
`reg_sequence` pattern and thus this is causing a selection failure in
hip test. Recreate a new patch with an alternative pattern, and added a
ll test global-extload-gfx11plus.ll
A call through a function pointer has no associated FunctionDecl, but it
still might have a nodiscard return type. Ensure there is a codepath to
emit the nodiscard warning in this case.
Fixes#142453
Building with assertions flag (-sAssertions=2) gives me these
```
[ RUN ] InterpreterTest.InstantiateTemplate Aborted(Assertion failed: undefined symbol '__clang_Interpreter_SetValueWithAlloc'. perhaps a side module was not linked in? if this global was expected to arrive from a system library, try to build the MAIN_MODULE with EMCC_FORCE_STDLIBS=1 in the environment) Error in loading dynamic library incr_module_3.wasm: RuntimeError: Aborted(Assertion failed: undefined symbol '__clang_Interpreter_SetValueWithAlloc'. perhaps a side module was not linked in? if this global was expected to arrive from a system library, try to build the MAIN_MODULE with EMCC_FORCE_STDLIBS=1 in the environment) Could not load dynamic lib: incr_module_3.wasm RuntimeError: Aborted(Assertion failed: undefined symbol '__clang_Interpreter_SetValueWithAlloc'. perhaps a side module was not linked in? if this global was expected to arrive from a system library, try to build the MAIN_MODULE with EMCC_FORCE_STDLIBS=1 in the environment)
[ RUN ] InterpreterTest.InstantiateTemplate Aborted(Assertion failed: undefined symbol '__clang_Interpreter_SetValueNoAlloc'. perhaps a side module was not linked in? if this global was expected to arrive from a system library, try to build the MAIN_MODULE with EMCC_FORCE_STDLIBS=1 in the environment) Error in loading dynamic library incr_module_3.wasm: RuntimeError: Aborted(Assertion failed: undefined symbol '__clang_Interpreter_SetValueNoAlloc'. perhaps a side module was not linked in? if this global was expected to arrive from a system library, try to build the MAIN_MODULE with EMCC_FORCE_STDLIBS=1 in the environment) Could not load dynamic lib: incr_module_3.wasm RuntimeError: Aborted(Assertion failed: undefined symbol '__clang_Interpreter_SetValueNoAlloc'. perhaps a side module was not linked in? if this global was expected to arrive from a system library, try to build the MAIN_MODULE with EMCC_FORCE_STDLIBS=1 in the environment)
[ RUN ] InterpreterTest.InstantiateTemplate Aborted(Assertion failed: undefined symbol '_ZnwmPv26__clang_Interpreter_NewTag'. perhaps a side module was not linked in? if this global was expected to arrive from a system library, try to build the MAIN_MODULE with EMCC_FORCE_STDLIBS=1 in the environment) Error in loading dynamic library incr_module_23.wasm: RuntimeError: Aborted(Assertion failed: undefined symbol '_ZnwmPv26__clang_Interpreter_NewTag'. perhaps a side module was not linked in? if this global was expected to arrive from a system library, try to build the MAIN_MODULE with EMCC_FORCE_STDLIBS=1 in the environment) Could not load dynamic lib: incr_module_23.wasm RuntimeError: Aborted(Assertion failed: undefined symbol '_ZnwmPv26__clang_Interpreter_NewTag'. perhaps a side module was not linked in? if this global was expected to arrive from a system library, try to build the MAIN_MODULE with EMCC_FORCE_STDLIBS=1 in the environment)
[ RUN ] InterpreterTest.Value Aborted(Assertion failed: undefined symbol '_Z9getGlobalv'. perhaps a side module was not linked in? if this global was expected to arrive from a system library, try to build the MAIN_MODULE with EMCC_FORCE_STDLIBS=1 in the environment) Error in loading dynamic library incr_module_36.wasm: RuntimeError: Aborted(Assertion failed: undefined symbol '_Z9getGlobalv'. perhaps a side module was not linked in? if this global was expected to arrive from a system library, try to build the MAIN_MODULE with EMCC_FORCE_STDLIBS=1 in the environment) Could not load dynamic lib: incr_module_36.wasm
[ RUN ] InterpreterTest.Value Aborted(Assertion failed: undefined symbol '_Z9getGlobalv'. perhaps a side module was not linked in? if this global was expected to arrive from a system library, try to build the MAIN_MODULE with EMCC_FORCE_STDLIBS=1 in the environment) Error in loading dynamic library incr_module_36.wasm: RuntimeError: Aborted(Assertion failed: undefined symbol '_Z9setGlobali'. perhaps a side module was not linked in? if this global was expected to arrive from a system library, try to build the MAIN_MODULE with EMCC_FORCE_STDLIBS=1 in the environment) Could not load dynamic lib: incr_module_36.wasm
```
**So we have some symbols missing here that are needed by the side
modules being created here.**
First 2 are needed by both tests
Last 3 are needed for these lines accordingly in the Value test.
dc23869f98/clang/unittests/Interpreter/InterpreterTest.cpp (L355)dc23869f98/clang/unittests/Interpreter/InterpreterTest.cpp (L364)dc23869f98/clang/unittests/Interpreter/InterpreterTest.cpp (L365)
Everything should work as expected after this
```
[----------] 9 tests from InterpreterTest
[ RUN ] InterpreterTest.Sanity
[ OK ] InterpreterTest.Sanity (18 ms)
[ RUN ] InterpreterTest.IncrementalInputTopLevelDecls
[ OK ] InterpreterTest.IncrementalInputTopLevelDecls (45 ms)
[ RUN ] InterpreterTest.Errors
[ OK ] InterpreterTest.Errors (29 ms)
[ RUN ] InterpreterTest.DeclsAndStatements
[ OK ] InterpreterTest.DeclsAndStatements (34 ms)
[ RUN ] InterpreterTest.UndoCommand
/Users/anutosh491/work/llvm-project/clang/unittests/Interpreter/InterpreterTest.cpp:156: Skipped
Test fails for Emscipten builds
[ SKIPPED ] InterpreterTest.UndoCommand (0 ms)
[ RUN ] InterpreterTest.FindMangledNameSymbol
[ OK ] InterpreterTest.FindMangledNameSymbol (85 ms)
[ RUN ] InterpreterTest.InstantiateTemplate
[ OK ] InterpreterTest.InstantiateTemplate (127 ms)
[ RUN ] InterpreterTest.Value
[ OK ] InterpreterTest.Value (608 ms)
[ RUN ] InterpreterTest.TranslationUnit_CanonicalDecl
[ OK ] InterpreterTest.TranslationUnit_CanonicalDecl (64 ms)
[----------] 9 tests from InterpreterTest (1014 ms total)
```
This is similar to how we need to take care of some symbols while
building side modules during running cppinterop's test suite !
This is helping some windows users, here is the doc:
**LLVM_LIT_TOOLS_DIR**:PATH
The path to GnuWin32 tools for tests. Valid on Windows host. Defaults to
the empty string, in which case lit will look for tools needed for tests
(e.g. ``grep``, ``sort``, etc.) in your ``%PATH%``. If GnuWin32 is not
in your
``%PATH%``, then you can set this variable to the GnuWin32 directory so
that
lit can find tools needed for tests in that directory.
In setVectorizedCallDecision we attempt to calculate the scalar costs
for vectorisation calls, even for scalable VFs where we already know the
answer is Invalid. We can avoid doing unnecessary work by skipping this
completely for scalable vectors.
64-bit version of 7425af4b7aaa31da10bd1bc7996d3bb212c79d88. We
still need to lower to 32-bit v_accagpr_write_b32s, so this has
a unique value restriction that requires both halves of the constant
to be 32-bit inline immediates. This only introduces the new
pseudo definitions, but doesn't try to use them yet.
This patch adds support for atomic loads and stores. Specifically, it
adds support for the following intrinsic calls:
- `__atomic_load` and `__atomic_store`;
- `__c11_atomic_load` and `__c11_atomic_store`.
LoopPeel currently considers PHI nodes that become loop invariants
through peeling. However, in some cases, peeling transforms PHI nodes
into induction variables (IVs), potentially enabling further
optimizations such as loop vectorization. For example:
```c
// TSVC s292
int im = N-1;
for (int i=0; i<N; i++) {
a[i] = b[i] + b[im];
im = i;
}
```
In this case, peeling one iteration converts `im` into an IV, allowing
it to be handled by the loop vectorizer.
This patch adds a new feature to peel loops when to convert PHIs into
IVs. At the moment this feature is disabled by default.
Enabling it allows to vectorize the above example. I have measured on
neoverse-v2 and observed a speedup of more than 60% (options: `-O3
-ffast-math -mcpu=neoverse-v2 -mllvm -enable-peeling-for-iv`).
This PR is taken over from #94900
Related #81851
SILoadStoreOptimizer can now recognise consecutive 16-bit and 8-bit
`TBUFFER_LOAD`/`TBUFFER_STORE` instructions that each write
* a single component (`X`), or
* two components (`XY`),
and fold them into the wider native variants:
```
X + X --> XY
X + X + X + X --> XYZW
XY + XY --> XYZW
X + X + X --> XYZ
XY + X --> XYZ
```
The optimisation cuts the number of TBUFFER instructions, shrinking code
size and improving memory throughput.
This is an attempt to reland #151660 by including a missing STL header
found by a buildbot failure.
The stable function map could be huge for a large application. Fully
loading it is slow and consumes a significant amount of memory, which is
unnecessary and drastically slows down compilation especially for
non-LTO and distributed-ThinLTO setups. This patch introduces an opt-in
lazy loading support for the stable function map. The detailed changes
are:
- `StableFunctionMap`
- The map now stores entries in an `EntryStorage` struct, which includes
offsets for serialized entries and a `std::once_flag` for thread-safe
lazy loading.
- The underlying map type is changed from `DenseMap` to
`std::unordered_map` for compatibility with `std::once_flag`.
- `contains()`, `size()` and `at()` are implemented to only load
requested entries on demand.
- Lazy Loading Mechanism
- When reading indexed codegen data, if the newly-introduced
`-indexed-codegen-data-lazy-loading` flag is set, the stable function
map is not fully deserialized up front. The binary format for the stable
function map now includes offsets and sizes to support lazy loading.
- The safety of lazy loading is guarded by the once flag per function
hash. This guarantees that even in a multi-threaded environment, the
deserialization for a given function hash will happen exactly once. The
first thread to request it performs the load, and subsequent threads
will wait for it to complete before using the data. For single-threaded
builds, the overhead is negligible (a single check on the once flag).
For multi-threaded scenarios, users can omit the flag to retain the
previous eager-loading behavior.
When testing LLDB, we want to make sure to use the same Python as the
one we used to build it.
We already did this in https://github.com/llvm/llvm-project/pull/143183
for the Unit and Shell tests. This patch does the same thing for the API
tests as well.
This patch reworks how VG is handled around streaming mode changes.
Previously, for functions with streaming mode changes, we would:
- Save the incoming VG in the prologue
- Emit `.cfi_offset vg, <offset>` and `.cfi_restore vg` around streaming
mode changes
Additionally, for locally streaming functions, we would:
- Also save the streaming VG in the prologue
- Emit `.cfi_offset vg, <incoming VG offset>` in the prologue
- Emit `.cfi_offset vg, <streaming VG offset>` and `.cfi_restore vg`
around streaming mode changes
In both cases, this ends up doing more than necessary and would be hard
for an unwinder to parse, as using `.cfi_offset` in this way does not
follow the semantics of the underlying DWARF CFI opcodes.
So the new scheme in this patch is to:
In functions with streaming mode changes (inc locally streaming)
- Save the incoming VG in the prologue
- Emit `.cfi_offset vg, <offset>` in the prologue (not at streaming mode
changes)
- Emit `.cfi_restore vg` after the saved VG has been deallocated
- This will be in the function epilogue, where VG is always the same as
the entry VG
- Explicitly reference the incoming VG expressions for SVE callee-saves
in functions with streaming mode changes
- Ensure the CFA is not described in terms of VG in functions with
streaming mode changes
A more in-depth discussion of this scheme is available in:
https://gist.github.com/MacDue/b7a5c45d131d2440858165bfc903e97b
But the TLDR is that following this scheme, SME unwinding can be
implemented with minimal changes to existing unwinders. All unwinders
need to do is initialize VG to `CNTD` at the start of unwinding, then
everything else is handled by standard opcodes (which don't need changes
to handle VG).
Fixes#150163
MLIR bytecode does not preserve alias definitions, so each attribute
encountered during deserialization is treated as a new one. This can
generate duplicate `DISubprogram` nodes during deserialization.
The patch adds a `StringMap` cache that records attributes and fetches
them when encountered again.
This patch implements pages 15-17 from
jhauser.us/RISCV/ext-P/RVP-instrEncodings-015.pdf
Documentation:
jhauser.us/RISCV/ext-P/RVP-baseInstrs-014.pdf
jhauser.us/RISCV/ext-P/RVP-instrEncodings-015.pdf
Summary:
It's extremely common to conditionally blend two vectors. Previously
this was done with mask registers, which is what the normal ternary code
generation does when used on a vector. However, since Clang 15 we have
supported boolean vector types in the compiler. These are useful in
general for checking the mask registers, but are currently limited
because they do not map to an LLVM-IR select instruction.
This patch simply relaxes these checks, which are technically forbidden
by
the OpenCL standard. However, general vector support should be able to
handle these. We already support this for Arm SVE types, so this should
be make more consistent with the clang vector type.
Fix the `sys.path` logic in the GDB plugin to insert the intended
self-path in the first position rather than appending it to the end. The
latter implied that if `sys.path` (naturally) contained the GDB's
`gdb-plugin` directory, `import ompd` would return the top-level
`ompd/__init__.py` module rather than the `ompd/ompd.py` submodule, as
intended by adding the `ompd/` directory to `sys.path`.
This is intended to be a minimal change necessary to fix the issue.
Alternatively, the code could be modified to import `ompd.ompd` and stop
modifying `sys.path` entirely. However, I do not know why this option
was chosen in the first place, so I can't tell if this won't break
something.
Fixes#153954
Signed-off-by: Michał Górny <mgorny@gentoo.org>
Both these functions update an `AllocInfoMap` structure in the context,
however they did not use any locks, causing random failures in threaded
code. Now they use a mutex.
These builtins are modeled on the clzg/ctzg builtins, which accept an
optional second argument. This second argument is returned if the first
argument is 0. These builtins unconditionally exhibit zero-is-undef
behaviour, regardless of target preference for the other ctz/clz
builtins. The builtins have constexpr support.
Fixes#154113
Unlike CVTTP2SI, CVTTP2UI is only available on AVX512 targets, so we
don't fallback to the AVX1 variant when we split a 512-bit vector, so we
can only use the 128/256-bit variants if we have AVX512VL.
Fixes#154492
After a485e0e, we may not set the vector trip count in
preparePlanForEpilogueVectorLoop if it is zero. We should not choose a
VF * UF that makes the main vector loop dead (i.e. vector trip count is
zero), but there are some cases where this can happen currently.
In those cases, set EPI.VectorTripCount to zero.
This patch adds the constant attribute to cir.global, the appropriate
lowering to LLVM constant and updates the tests.
---------
Co-authored-by: Andy Kaylor <akaylor@nvidia.com>
When moving fcti results from float registers to normal registers
through memory, even though MPI was adjusted to account for endianness,
FIPtr was always adjusted for big-endian, which caused loads of wrong
half of a value in little-endian mode.
`std::wstring AnsiToUtf16(const std::string &ansi)` is a
reimplementation of `llvm::sys::windows::UTF8ToUTF16`. This patch
removes `AnsiToUtf16` and its usages entirely.
Both these attributes were introduced in ab1dc2d54db5 ("Thread Safety
Analysis: add support for before/after annotations on mutexes") back in
2015 as "beta" features.
Anecdotally, we've been using `-Wthread-safety-beta` for years without
problems.
Furthermore, this feature requires the user to explicitly use these
attributes in the first place.
After 10 years, let's graduate the feature to the stable feature set,
and reserve `-Wthread-safety-beta` for new upcoming features.
The AArch64 build attribute specification now allows switching to an
already-defined subsection using its name alone, without repeating the
optionality and type parameters.
This patch updates the parser to support that behavior.
Spec reference: https://github.com/ARM-software/abi-aa/pull/230/files
If FunctionAttrs infers additional attributes on a function, it also
invalidates analysis on callers of that function. The way it does this
right now limits this to calls with matching signature. However, the
function attributes will also be used when the signatures do not match.
Use getCalledOperand() to avoid a signature check.
This is not a correctness fix, just improves analysis quality. I noticed
this due to
https://github.com/llvm/llvm-project/pull/144497#issuecomment-3199330709,
where LICM ends up with a stale MemoryDef that could be a MemoryUse
(which is a bug in LICM, but still non-optimal).
Whether the argument is fixed is now available via ArgFlags, so make use
of it. The previous implementation was quite problematic, because it
stored the number of fixed arguments in a global variable, which is not
thread safe.
The immediate evaluation context needs the lambda scope info to
propagate some flags, however that LSI was removed in
ActOnFinishFunctionBody which happened before rebuilding a lambda
expression.
The last attempt destroyed LSI at the end of the block scope, after
which we still need it in DiagnoseShadowingLambdaDecls.
This also converts the wrapper function to default arguments as a
drive-by fix, as well as does some cleanup.
Fixes https://github.com/llvm/llvm-project/issues/145776
Add trailing newlines to the following files to comply with POSIX
standards:
- llvm/lib/Target/RISCV/RISCVInstrInfoXSpacemiT.td
- llvm/test/MC/RISCV/xsmtvdot-invalid.s
- llvm/test/MC/RISCV/xsmtvdot-valid.s
Closes#151706
This is a cherry pick of #154053 with a fix for bad handling of
endianess when loading float and double litteral from the binary.
---------
Co-authored-by: Ferdinand Lemaire <ferdinand.lemaire@woven-planet.global>
Co-authored-by: Jessica Paquette <jessica.paquette@woven-planet.global>
Co-authored-by: Luc Forget <luc.forget@woven.toyota>
In streaming mode, both the @llvm.aarch64.sme.cnts and @llvm.aarch64.sve.cnt
intrinsics are equivalent. For SVE, cnt* is lowered in instCombineIntrinsic
to @llvm.sme.vscale(). This patch lowers the SME intrinsic similarly when
in streaming-mode.
This patch handle struct of fixed vector and struct of array of fixed
vector correctly for VLS calling convention in EmitFunctionProlog,
EmitFunctionEpilog and EmitCall.
stack on: https://github.com/llvm/llvm-project/pull/147173
I was looking over this pass and noticed it was using shared pointers
for CompositeNodes. However, all nodes are owned by the deinterleaving
graph and are not released until the graph is destroyed. This means a
bump allocator and raw pointers can be used, which have a simpler
ownership model and less overhead than shared pointers.
The changes in this PR are to:
- Add a `SpecificBumpPtrAllocator<CompositeNode>` to the
`ComplexDeinterleavingGraph`
- This allocates new nodes and will deallocate them when the graph is
destroyed
- Replace `NodePtr` and `RawNodePtr` with `CompositeNode *`
This updates the fp<->int tests to include some store(fptoi) and itofp(load)
test cases. It also cuts down on the number of large vector cases which are not
testing anything new.
In relation to the approval and merge of the
https://github.com/llvm/llvm-project/pull/76088 specification about
multi-image features in Flang.
Here is a PR on adding support for `THIS_IMAGE` and `NUM_IMAGES` in
conformance with the PRIF specification.
For `THIS_IMAGE`, the lowering to the subroutine containing the coarray
argument is not present in this PR, and will be in a future one.
This change introduces a new kernel attribute that allows thread blocks to be mapped to clusters.
In addition, it also adds support of `+ptx90` PTX ISA support.
orc-rt/test/unit/lit.site.cfg.py.in was pointing to the lit.cfg.py file for the
regression tests, causing the `check-orc-rt-unit` target to re-run the
regression tests rather than running the unit tests.
This is where they belong, no need to maintain a separate map keyed by
encoding ID.
`populateInstruction()` has been made a member of `InstructionEncoding`
and is now called from the constructor.
The import and include problem is a long-standing issue with the use of
C++20 modules. This patch tried to improve this by skipping parsing
class and functions if their declaration is already defined in modules.
The scale of the patch itself is small as the patch reuses previous
optimization. Maybe we can skip parsing other declarations in the
future. But the patch itself should be good.
On glibc x86-64, functions like pthread_cond_init exist in two versions:
2.2 (older pthread_cond_t) and 2.3.2 (newer pthread_cond_t). In glibc
versions prior to 2.36, using an unversioned interceptor
(`dlsym(RTLD_NEXT, "pthread_cond_init")`) retrieves the older 2.2
symbol, which is not desired
(https://sourceware.org/bugzilla/show_bug.cgi?id=14932).
For newer architectures, such as aarch64 (introduced in glibc 2.17) and
riscv64 (introduced in glibc 2.27), a versioned interceptor is
unnecessary.
Pull Request: https://github.com/llvm/llvm-project/pull/154268
For the common pattern:
```C++
module;
export module a;
...
```
```C++
// a.cpp
import a;
```
In this case, we're already able to skip parsing the body of some
declarations in a.cpp. Add a test to show the ability.
This is needed to handle the scenario of an extension that implies
FeatureStdExtE, as is the case for the
downstream FeatureVendorXCheriot used for Cheriot support.
When rematerialize a virtual register the register may be early
clobbered.
However rematerializeAt(...) just return the slot index of Slot_Register
which cause mis-calculating live range for the register
---------
Co-authored-by: Yuanke Luo <ykluo@birentech.com>
Verify it's a multiple of the result vector element count
instead of asserting this in random combines.
The testcase in #153808 fails in the wrong point. Add an
assert to getNode so the invalid extract asserts at construction
instead of use.
Currently HwASan has no fiber switch interface for coroutines. This PR
adds fiber switch interfaces similar to ASan which helps to pass sp
check correctly on unwinding.
The only difference is HwASan does not need a fake stack since tags can
do the same thing (e.g., detect UAR). Interfaces are made identical with
ASan's.
Also adds unit test which is similar to ASan with minor adjustments:
1. change `__asan_handle_no_return` to `__hwasan_handle_vfork`
2. remove huge stack test since `__hwasan_handle_vfork` has no stack
size limitation.
3. use uninstrumented globals to simulate allocation since hwasan do not
support tagged pointer while using `longjmp`
The testcase is tested on both x86 with alias mode enabled and aarch64.
Follow-up to #154288.
With HwModes involved, we used to analyze the same encoding multiple
times (unless `-suppress-per-hwmode-duplicates=O2` is specified). This
affected the build time and made the statistics inaccurate.
From the point of view of the generated code, this is an NFC.
Improve error handling in ObjectFileWasm by using helpers that wrap
their result in an llvm::Expected. The helper to read a Wasm string now
return an Expected<std::string> and I created a helper to parse 32-bit
ULEBs that returns an Expected<uint32_t>.
This PR fixes the access to bitfields inside a union.
Previously, we were using a `getMemberOp` to access the field, but
because it is a union, `getMemberOp` would always use index `0`.
For example, given:
```c
typedef union {
int x;
int y : 4;
int z : 8;
} demo;
```
```mlir
!rec_demo = !cir.record<union "demo" {!s32i, !u8i, !u8i}>
```
In the case of:
```c
d.y = 2;
```
It would generate:
```mlir
cir.get_member %0[0] {name = "y"} : !cir.ptr<!rec_demo> -> !cir.ptr<!s32i>
```
with a return type of `!s32i`, when it should be `!u8i`.
the get_member verifier would detect that the return type does not match
the `y` member.
To fix this, we now use `bitcast` to get the start of the union.
We have a flag that tracks whether a `CXXThisExpr` refers to a `*this`
capture in a lambda with a dependent explicit object parameter; this is
to mark it and member accesses involving it as dependent because there
is no other way to track that (DREs have a similar flag); when
instantiating the lambda, we need to always rebuild the `CXXThisExpr` to
potentially clear that flag if the explicit object parameter is no
longer dependent.
Fixes#154054.
Makes sure UnconventionalAssignOperatorCheck checks if the types
reference the same entity, not the exact declaration.
This adds a new matcher to support this check.
This fixes a regression introduced by #147835. Since this regression was
never released, there are no release notes.
Fixes#153770
This is a follow-up to #150963. X86 HLT instruction may appear in the
user-level code, in which case we should treat it as a terminator.
Handle it as a non-terminator in the Linux kernel mode.
added getName method in SBModule.h and .cpp in order to get the name of
the module from m_object_name.
---------
Co-authored-by: Bar Soloveychik <barsolo@fb.com>
Recent changes introduced custom lowering for bf16 fdiv on targets that
support bf16 trans instructions, but only covered the unsafe version.
This PR extends that support to the safe variant.
For the safe version, the op is lowered by converting to float,
performing the div in float, and converting the result back to bf16.
This matches the behavior on targets that don't support bf16 trans
instructions.
Fixes SWDEV-550381.
Exposes the `tensor.extract_slice` reshaping logic in
`BubbleUpExpandShapeThroughExtractSlice` and
`BubbleUpCollapseShapeThroughExtractSlice` through two corresponding
utility functions. These compute the offsets/sizes/strides of an extract
slice after either collapsing or expanding.
This should also make it easier to implement the two other bubbling
cases: (1) the `collapse_shape` is a consumer or (2) the `expand_shape`
is a consumer.
---------
Signed-off-by: Ian Wood <ianwood@u.northwestern.edu>
When assigning numbers to registers, skip any with neither uses nor
defs. This is will not have any impact at all on the final SASS but it
makes for slightly more readable PTX. This change should also ensure
that future minor changes are less likely to cause noisy diffs in
register numbering.
This patch replaces SmallSet<T *, N> with SmallPtrSet<T *, N>. Note
that SmallSet.h "redirects" SmallSet to SmallPtrSet for pointer
element types:
template <typename PointeeType, unsigned N>
class SmallSet<PointeeType*, N> : public SmallPtrSet<PointeeType*, N>
{};
We only have 10 instances that rely on this "redirection". Since the
redirection doesn't improve readability, this patch replaces SmallSet
with SmallPtrSet for pointer element types.
I'm planning to remove the redirection eventually.
If an array initializer list leaves eight or more elements that require
zero fill, we had been generating an individual zero element for every
one of them. This change instead follows the behavior of classic
codegen, which creates a constant structure with the specified elements
followed by a zero-initializer for the trailing zeros.
Fix incorrect super-register lookup when copying from $wzr on subtargets
that lack zero-cycle zeroing but support 64-bit zero-cycle moves.
When copying from $wzr, we used the wrong register class to lookup the
super-register, causing
$w0 = COPY $wzr
to get expanded as
$x0 = ORRXrr $xzr, undef $noreg, implicit $wzr,
rather than the correct
$x0 = ORRXrr $xzr, undef $xzr, implicit $wzr.
Before this change, `-quiet` mode in clang-tidy generated meaningless
messages `xxx warnings generated` in output:
```cpp
// main.cpp
#include <iostream>
int main() {
std::cout << 42;
}
```
```console
> clang-tidy -checks='-*,readability-magic-numbers' -quiet main.cpp
82 warnings generated.
main.cpp:4:16: warning: 42 is a magic number; consider replacing it with a named constant [readability-magic-numbers]
4 | std::cout << 42;
| ^
```
As you can see, `82 warnings generated.` does not say much `quiet` mode,
this patch removes this message completely:
```console
> ./build/bin/clang-tidy -p build -checks='-*,readability-magic-numbers' -quiet main.cpp
main.cpp:4:16: warning: 42 is a magic number; consider replacing it with a named constant [readability-magic-numbers]
4 | std::cout << 42;
| ^
```
In contrast, when running without `quiet`, It gives some meaningful
information because we know how many messages were suppressed thus
calculating total messages count:
```console
> clang-tidy -checks='-*,readability-magic-numbers' main.cpp
82 warnings generated.
main.cpp:4:16: warning: 42 is a magic number; consider replacing it with a named constant [readability-magic-numbers]
4 | std::cout << 42;
| ^
Suppressed 81 warnings (81 in non-user code).
Use -header-filter=.* to display errors from all non-system headers. Use -system-headers to display errors from system headers as well.
```
Fixes#47042
This is a continuation of #153494. In a WebAssembly file, the "name"
section contains names for the segments in the data section
(WASM_NAMES_DATA_SEGMENT). We already parse these as symbols, and with
this PR, we now also create sub-sections for each of the segments.
In C++, it can be assumed the same linkage will be computed for all
redeclarations of an entity, and we have assertions to check this.
However, the linkage for a declaration can be requested in the middle of
deserealization, and at this point the redecl chain is not well formed,
as computation of the most recent declaration is deferred.
This patch makes that assertion work even in such conditions.
This fixes a regression introduced in
https://github.com/llvm/llvm-project/pull/147835, which was never
released, so there are no release notes for this.
Fixes#153933
Revert llvm/llvm-project#154018 changes due to excessive _false
positives_. The warning caused multiple benign reports in large
codebases (e.g. _Linux kernel_, _Fuchsia_, _tcpdump_). Since many of
these concatenations are intentional and follow project style rules, the
diagnostic introduced more false positives than value. This will be
revisited as a potential `clang-tidy` check instead.
This patch works towards consolidating all Clang debug-info into the
`clang/test/DebugInfo` directory
(https://discourse.llvm.org/t/clang-test-location-of-clang-debug-info-tests/87958).
Here we move only the `clang/test/CodeGen` tests.
The list of files i came up with is:
1. searched for anything with `*debug-info*` in the filename
2. searched for occurrences of `debug-info-kind` in the tests
I created a couple of subdirectories in `clang/test/DebugInfo` where I
thought it made sense (mostly when the tests were target-specific).
There's a couple of tests in `clang/test/CodeGen` that still set
`-debug-info-kind`. They probably don't need to do that, but I'm not
changing that as part of this PR.
This can happen when JIT code is run, and we can't symbolize those
frames, but they should remain numbered in the stack. An example
spidermonkey trace:
```
#0 0x564ac90fb80f (/builds/worker/dist/bin/js+0x240e80f) (BuildId: 5d053c76aad4cfbd08259f8832e7ac78bbeeab58)
#1 0x564ac9223a64 (/builds/worker/dist/bin/js+0x2536a64) (BuildId: 5d053c76aad4cfbd08259f8832e7ac78bbeeab58)
#2 0x564ac922316f (/builds/worker/dist/bin/js+0x253616f) (BuildId: 5d053c76aad4cfbd08259f8832e7ac78bbeeab58)
#3 0x564ac9eac032 (/builds/worker/dist/bin/js+0x31bf032) (BuildId: 5d053c76aad4cfbd08259f8832e7ac78bbeeab58)
#4 0x0dec477ca22e (<unknown module>)
```
Without this change, the following symbolization is output:
```
#0 0x55a6d72f980f in MOZ_CrashSequence /builds/worker/workspace/obj-build/dist/include/mozilla/Assertions.h:248:3
#1 0x55a6d72f980f in Crash(JSContext*, unsigned int, JS::Value*) /builds/worker/checkouts/gecko/js/src/shell/js.cpp:4223:5
#2 0x55a6d7421a64 in CallJSNative(JSContext*, bool (*)(JSContext*, unsigned int, JS::Value*), js::CallReason, JS::CallArgs const&) /builds/worker/checkouts/gecko/js/src/vm/Interpreter.cpp:501:13
#3 0x55a6d742116f in js::InternalCallOrConstruct(JSContext*, JS::CallArgs const&, js::MaybeConstruct, js::CallReason) /builds/worker/checkouts/gecko/js/src/vm/Interpreter.cpp:597:12
#4 0x55a6d80aa032 in js::jit::DoCallFallback(JSContext*, js::jit::BaselineFrame*, js::jit::ICFallbackStub*, unsigned int, JS::Value*, JS::MutableHandle<JS::Value>) /builds/worker/checkouts/gecko/js/src/jit/BaselineIC.cpp:1705:10
#4 0x2c803bd8f22e (<unknown module>)
```
The last frame has a duplicate number. With this change the numbering is
correct:
```
#0 0x5620c58ec80f in MOZ_CrashSequence /builds/worker/workspace/obj-build/dist/include/mozilla/Assertions.h:248:3
#1 0x5620c58ec80f in Crash(JSContext*, unsigned int, JS::Value*) /builds/worker/checkouts/gecko/js/src/shell/js.cpp:4223:5
#2 0x5620c5a14a64 in CallJSNative(JSContext*, bool (*)(JSContext*, unsigned int, JS::Value*), js::CallReason, JS::CallArgs const&) /builds/worker/checkouts/gecko/js/src/vm/Interpreter.cpp:501:13
#3 0x5620c5a1416f in js::InternalCallOrConstruct(JSContext*, JS::CallArgs const&, js::MaybeConstruct, js::CallReason) /builds/worker/checkouts/gecko/js/src/vm/Interpreter.cpp:597:12
#4 0x5620c669d032 in js::jit::DoCallFallback(JSContext*, js::jit::BaselineFrame*, js::jit::ICFallbackStub*, unsigned int, JS::Value*, JS::MutableHandle<JS::Value>) /builds/worker/checkouts/gecko/js/src/jit/BaselineIC.cpp:1705:10
#5 0x349f24c7022e (<unknown module>)
```
The changes from https://github.com/llvm/llvm-project/pull/136855 missed
a change with atomic assignment constraints. This fixes a bug where we'd
accidentally drop a non-atomic-to-atomic conversion step.
Fixes#154157
co-authored-by: @ahatanak
This PR adds the following basic math functions for BFloat16 type along
with the tests:
- fromfpbf16
- fromfpxbf16
- ufromfpbf16
- ufromfpxbf16
---------
Signed-off-by: Krishna Pandey <kpandey81930@gmail.com>
Previously, we fold `(vfmv.s.f (extract_subvector X, 0))` into X when
X's type is the same as `vfmv.s.f`'s result type. This patch generalizes
it by folding it into insert_subvector when X is narrower and
extract_subvector when X is wider.
Co-authored-by: Craig Topper <craig.topper@sifive.com>
If alignment inference happens after NVPTXLowerArgs these addrspace wrap
intrinsics can prevent computeKnownBits from deriving alignment of
loads/stores from parameters. To solve this, we can insert an alignment
annotation on the generated intrinsic so that computeKnownBits does not
need to traverse through it to find the alignment.
This patch replaces SmallSet<T *, N> with SmallPtrSet<T *, N>. Note
that SmallSet.h "redirects" SmallSet to SmallPtrSet for pointer
element types:
template <typename PointeeType, unsigned N>
class SmallSet<PointeeType*, N> : public SmallPtrSet<PointeeType*, N>
{};
We only have 10 instances that rely on this "redirection". Since the
redirection doesn't improve readability, this patch replaces SmallSet
with SmallPtrSet for pointer element types.
I'm planning to remove the redirection eventually.
This patch replaces SmallSet<T *, N> with SmallPtrSet<T *, N>. Note
that SmallSet.h "redirects" SmallSet to SmallPtrSet for pointer
element types:
template <typename PointeeType, unsigned N>
class SmallSet<PointeeType*, N> : public SmallPtrSet<PointeeType*, N>
{};
We only have 10 instances that rely on this "redirection", with more
than half of them under clang-tools-extra/. Since the redirection
doesn't improve readability, this patch replaces SmallSet with
SmallPtrSet for pointer element types.
I'm planning to remove the redirection eventually.
Summary:
This is a standalone tool that does the wrapper stage of the
`clang-linker-wrapper`. We want this to be an external tool because
currently there's no easy way to split apart what the
clang-linker-wrapper is doing under the hood. With this tool, users can
manually extract files with `clang-offload-packager`, feed them through
`clang --target=<triple>` and then use this tool to generate a `.bc`
file they can give to the linker. The goal here is to make reproducing
the linker wrapper steps easier.
The seemingly was a regression that prevented the usage of named
constant (w/ PARAMETER attribute) in SHARED and FIRSTPRIVATE clauses.
This PR corrects that.
This abstracts the base Transport handler to have a MessageHandler
component and allows us to generalize both JSON-RPC 2.0 for MCP (or an
LSP) and DAP format.
This should allow us to create clearly defined clients and servers for
protocols, both for testing and for RPC between the lldb instances and
an lldb-mcp multiplexer.
This basic model is inspiried by the clangd/Transport.h file and the
mlir/lsp-server-support/Transport.h that are both used for LSP servers
within the llvm project.
Additionally, this helps with testing by subclassing `Transport` to
allow us to simplify sending/receiving messages without needing to use a
toJSON/fromJSON and a pair of pipes, see `TestTransport` in
DAP/TestBase.h.
This reverts commit 5178aeff7b96e86b066f8407b9d9732ec660dd2e.
In addition:
* Scalar constant UNSIGNED BOUNDARY is explicitly casted
to the result type so that the generated hlfir.eoshift
operation is valid. The lowering produces signless constants
by default. It might be a bigger issue in lowering, so I just
want to "fix" it for EOSHIFT in this patch.
* Since we have to create unsigned integer constant during
HLFIR inlining, I added code in createIntegerConstant
to make it possible.
Array sections like this have not been using the knowledge that
the result is contiguous:
```
type t
integer :: f
end type
type(t) :: a(:)
a%f = 0
```
Peter Klausler is working on a change that will result in the
corresponding
hlfir.designate having a component and a non-box result.
This patch fixes the issues found in HLFIR-to-FIR conversion.
This patch fixes a regression introduced by #153819. The evaluation
order of the arguments to `emitVAStart` is unspecified, but the test
requires the arguments to be evaluated in left-to-right order.
It's a bit strange that the pre-merge checks did not catch this. The
tests failed on my local machine, which runs Fedora 42 with gcc 15.2.1 .
Introduces `_regexp-step`, a step command which additionally allows for
stepping into a target function. This change updates `step` and `s` to
be aliases for `_regexp-step`.
The existing `sif` alias ("Step Into Function") is not well known
amongst users. This change updates `step` and `s` to also work like
`sif`, taking an optional function name.
This is implemented to not break uses of `step` or `s` with a flag, for
example running `step -r func_to_avoid` works as expected.
The current code will crash on the MAP clause with OpenMP version >= 6.0
when the clause does not explicitly list any modifiers. The proper fix
is to update the handling of assumed-size arrays for OpenMP 6.0+, but in
the short term keep the behavior from 5.2, just avoid the crash.
This patch does the bare minimum to start setting up the reduction
recipe support, including adding a type to the AST to store it. No real
additional work is done, and a bunch of static_asserts are left around
to allow us to do this properly.
The Generic_GCC::GCCInstallationDetector class picks the GCC
installation directory with the largest version number. Since the
location of the libstdc++ include directories is tied to the GCC
version, this can break C++ compilation if the libstdc++ headers for
this particular GCC version are not available. Linux distributions tend
to package the libstdc++ headers separately from GCC. This frequently
leads to situations in which a newer version of GCC gets installed as a
dependency of another package without installing the corresponding
libstdc++ package. Clang then fails to compile C++ code because it
cannot find the libstdc++ headers. Since libstdc++ headers are in fact
installed on the system, the GCC installation continues to work, the
user may not be aware of the details of the GCC detection, and the
compiler does not recognize the situation and emit a warning, this
behavior can be hard to understand - as witnessed by many related bug
reports over the years.
The goal of this work is to change the GCC detection to prefer GCC
installations that contain libstdc++ include directories over those
which do not. This should happen regardless of the input language since
picking different GCC installations for a build that mixes C and C++
might lead to incompatibilities.
Any change to the GCC installation detection will probably have a
negative impact on some users. For instance, for a C user who relies on
using the GCC installation with the largest version number, it might
become necessary to use the --gcc-install-dir option to ensure that this
GCC version is selected.
This seems like an acceptable trade-off given that the situation for
users who do not have any special demands on the particular GCC
installation directory would be improved significantly.
This patch does not yet change the automatic GCC installation directory
choice. Instead, it does introduce a warning that informs the user about
the future change if the chosen GCC installation directory differs from
the one that would be chosen if the libstdc++ headers are taken into
account.
See also this related Discourse discussion:
https://discourse.llvm.org/t/rfc-take-libstdc-into-account-during-gcc-detection/86992.
This is equivalent to `cuOccupancyMaxPotentialBlockSize`. It is
currently
only implemented on Cuda; AMDGPU and Host return unsupported.
---------
Co-authored-by: Callum Fare <callum@codeplay.com>
This patch replaces SmallSet<T *, N> with SmallPtrSet<T *, N>. Note
that SmallSet.h "redirects" SmallSet to SmallPtrSet for pointer
element types:
template <typename PointeeType, unsigned N>
class SmallSet<PointeeType*, N> : public SmallPtrSet<PointeeType*, N>
{};
We only have 30 instances that rely on this "redirection". Since the
redirection doesn't improve readability, this patch replaces SmallSet
with SmallPtrSet for pointer element types.
I'm planning to remove the redirection eventually.
This patch replaces SmallSet<T *, N> with SmallPtrSet<T *, N>. Note
that SmallSet.h "redirects" SmallSet to SmallPtrSet for pointer
element types:
template <typename PointeeType, unsigned N>
class SmallSet<PointeeType*, N> : public SmallPtrSet<PointeeType*, N>
{};
We only have 30 instances that rely on this "redirection", with about
half of them under clang/. Since the redirection doesn't improve
readability, this patch replaces SmallSet with SmallPtrSet for pointer
element types.
I'm planning to remove the redirection eventually.
The immediate evaluation context needs the lambda scope info to
propagate some flags, however that LSI was removed in
ActOnFinishFunctionBody which happened before rebuilding a lambda
expression.
This also converts the wrapper function to default arguments as a
drive-by fix.
Fixes https://github.com/llvm/llvm-project/issues/145776
This patch is the last of the 'firstprivate' clause lowering patches. It
takes the already generated 'copy' init from Sema and uses it to
generate the IR for the copy section of the recipe.
However, one thing that this patch had to do, was come up with a way to
hijack the decl registration in CIRGenFunction. Because these decls are
being created in a 'different' place, we need to remove the things we've
added. We could alternatively generate these 'differently', but it seems
worth a little extra effort here to avoid having to re-implement
variable initialization.
## Description
This change introduces a new canonicalization pattern for the MLIR
Vector dialect that optimizes chains of insertions. The optimization
identifies when a vector is **completely** initialized through a series
of vector.insert operations and replaces the entire chain with a
single `vector.from_elements` operation.
Please be aware that the new pattern **doesn't** work for poison vectors
where only **some** elements are set, as MLIR doesn't support partial
poison vectors for now.
**New Pattern: InsertChainFullyInitialized**
* Detects chains of vector.insert operations.
* Validates that all insertions are at static positions, and all
intermediate insertions have only one use.
* Ensures the entire vector is **completely** initialized.
* Replaces the entire chain with a
single vector.from_elementts operation.
**Refactored Helper Function**
* Extracted `calculateInsertPosition` from
`foldDenseElementsAttrDestInsertOp` to avoid code duplication.
## Example
```
// Before:
%v1 = vector.insert %c10, %v0[0] : i64 into vector<2xi64>
%v2 = vector.insert %c20, %v1[1] : i64 into vector<2xi64>
// After:
%v2 = vector.from_elements %c10, %c20 : vector<2xi64>
```
It also works for multidimensional vectors.
```
// Before:
%v1 = vector.insert %cv0, %v0[0] : vector<3xi64> into vector<2x3xi64>
%v2 = vector.insert %cv1, %v1[1] : vector<3xi64> into vector<2x3xi64>
// After:
%0:3 = vector.to_elements %arg1 : vector<3xi64>
%1:3 = vector.to_elements %arg2 : vector<3xi64>
%v2 = vector.from_elements %0#0, %0#1, %0#2, %1#0, %1#1, %1#2 : vector<2x3xi64>
```
---------
Co-authored-by: Yang Bai <yangb@nvidia.com>
Co-authored-by: Andrzej Warzyński <andrzej.warzynski@gmail.com>
The previous debug output only showed numeric IDs for origins, making it
difficult to understand what each origin represented. This change makes
the debug output more informative by showing what kind of entity each
origin refers to (declaration or expression) and additional details like
declaration names or expression class names. This improved output makes
it easier to debug and understand the lifetime safety analysis.
Add the following properties in Offload device info:
* VENDOR_ID
* NUM_COMPUTE_UNITS
* [SINGLE|DOUBLE|HALF]_FP_CONFIG
* NATIVE_VECTOR_WIDTH_[CHAR|SHORT|INT|LONG|FLOAT|DOUBLE|HALF]
* MAX_CLOCK_FREQUENCY
* MEMORY_CLOCK_RATE
* ADDRESS_BITS
* MAX_MEM_ALLOC_SIZE
* GLOBAL_MEM_SIZE
Add a bitfield option to enumerators, allowing the values to be
bit-shifted instead of incremented. Generate the per-type enums using
`foreach` to reduce code duplication.
Use macros in unit test definitions to reduce code duplication.
This is the continuation of #152131
This PR adds support for parsing the global initializer and function
body, and support for decoding scalar numerical instructions and
variable related instructions.
---------
Co-authored-by: Ferdinand Lemaire <ferdinand.lemaire@woven-planet.global>
Co-authored-by: Jessica Paquette <jessica.paquette@woven-planet.global>
Co-authored-by: Luc Forget <luc.forget@woven.toyota>
2025-08-19 13:42:47 +02:00
2137 changed files with 144542 additions and 64207 deletions
The ``__coro_frame`` variable usually refers to the coroutine frame of an
*in-flight* coroutine. This means, the coroutine is currently executing.
*in-flight* coroutine. This means the coroutine is currently executing.
However, the compiler only guarantees the coroutine frame to be in a consistent
state while the coroutine is suspended. As such, the variables inside the
``__coro_frame`` variable might be outdated, in particular when optimizations
``__coro_frame`` variable might be outdated, particularly when optimizations
are enabled.
Furthermore, when optimizations are enabled, the compiler will layout the
@ -731,7 +731,7 @@ despite ``a`` being frequently incremented.
While this might be surprising, this is a result of the optimizer recognizing
that it can eliminate most of the load/store operations.
The above code gets optimized to the equivalent of:
The above code is optimized to the equivalent of:
..code-block:: c++
@ -1180,5 +1180,5 @@ The authors of the Folly libraries wrote a blog post series on how they debug co
* `Async stack traces in folly: Improving debugging in the developer lifecycle <https://developers.facebook.com/blog/post/2021/10/21/async-stack-traces-folly-improving-debugging-developer-lifecycle/>`_
Besides some topics also covered here (stack traces from the debugger), Folly's blog post series also covers
more additional topics, such as capturing async stack traces in performance profiles via eBPF filters
additional topics, such as capturing async stack traces in performance profiles via eBPF filters
@ -37,6 +37,22 @@ latest release, please see the `Clang Web Site <https://clang.llvm.org>`_ or the
Potentially Breaking Changes
============================
- Clang will now emit a warning if the auto-detected GCC installation
directory (i.e. the one with the largest version number) does not
contain libstdc++ include directories although a "complete" GCC
installation directory containing the include directories is
available. It is planned to change the auto-detection to prefer the
"complete" directory in the future. The warning will disappear if
the libstdc++ include directories are either installed or removed
for all GCC installation directories considered by the
auto-detection; see the output of ``clang -v`` for a list of those
directories. If the GCC installations cannot be modified and
maintaining the current choice of the auto-detection is desired, the
GCC installation directory can be selected explicitly using the
``--gcc-install-dir`` command line argument. This will silence the
warning. It can also be disabled using the
``-Wno-gcc-install-dir-libstdcxx`` command line flag.
C/C++ Language Potentially Breaking Changes
-------------------------------------------
@ -137,16 +153,41 @@ Non-comprehensive list of changes in this release
- ``__builtin_elementwise_max`` and ``__builtin_elementwise_min`` functions for integer types can
now be used in constant expressions.
- A vector of booleans is now a valid condition for the ternary ``?:`` operator.
This binds to a simple vector select operation.
- Added ``__builtin_masked_load`` and ``__builtin_masked_store`` for conditional
memory loads from vectors. Binds to the LLVM intrinsic of the same name.
- Use of ``__has_feature`` to detect the ``ptrauth_qualifier`` and ``ptrauth_intrinsics``
features has been deprecated, and is restricted to the arm64e target only. The
correct method to check for these features is to test for the ``__PTRAUTH__``
macro.
- Added a new builtin, ``__builtin_dedup_pack``, to remove duplicate types from a parameter pack.
This feature is particularly useful in template metaprogramming for normalizing type lists.
The builtin produces a new, unexpanded parameter pack that can be used in contexts like template
argument lists or base specifiers.
..code-block:: c++
template <typename...> struct TypeList;
// The resulting type is TypeList<int, double, char>
using MyTypeList = TypeList<__builtin_dedup_pack<int, double, int, char, double>...>;
Currently, the use of ``__builtin_dedup_pack`` is limited to template arguments and base
specifiers, it also must be used within a template context.
New Compiler Flags
------------------
- New option ``-fno-sanitize-annotate-debug-info-traps`` added to disable emitting trap reasons into the debug info when compiling with trapping UBSan (e.g. ``-fsanitize-trap=undefined``).
Lanai Support
^^^^^^^^^^^^^^
- The option ``-mcmodel={small,medium,large}`` is supported again.
Deprecated Compiler Flags
-------------------------
@ -168,8 +209,6 @@ Improvements to Clang's diagnostics
an override of a virtual method.
- Fixed fix-it hint for fold expressions. Clang now correctly places the suggested right
parenthesis when diagnosing malformed fold expressions. (#GH151787)
- ``-Wstring-concatenation`` now diagnoses every missing comma in an initializer list,
rather than stopping after the first. (#GH153745)
- Fixed an issue where emitted format-signedness diagnostics were not associated with an appropriate
diagnostic id. Besides being incorrect from an API standpoint, this was user visible, e.g.:
@ -186,6 +225,9 @@ Improvements to Clang's diagnostics
potential misaligned members get processed before they can get discarded.
(#GH144729)
- Fixed false positive in ``-Wmissing-noreturn`` diagnostic when it was requiring the usage of
``[[noreturn]]`` on lambdas before C++23 (#GH154493).
Improvements to Clang's time-trace
----------------------------------
@ -203,6 +245,7 @@ Bug Fixes in This Version
cast chain. (#GH149967).
- Fixed a crash with incompatible pointer to integer conversions in designated
@ -226,8 +226,8 @@ one-phase compilation model is simpler for build systems to implement while the
two-phase compilation has the potential to compile faster due to higher
parallelism. As an example, if there are two module units ``A`` and ``B``, and
``B`` depends on ``A``, the one-phase compilation model needs to compile them
serially, whereas the two-phase compilation model is able to be compiled as
soon as ``A.pcm`` is available, and thus can be compiled simultaneously as the
serially, whereas the two-phase compilation model can be compiled as
soon as ``A.pcm`` is available, and thus can be compiled simultaneously with the
``A.pcm`` to ``A.o`` compilation step.
File name requirements
@ -391,7 +391,7 @@ And the compilation processes for module units are like:
As the diagrams show, we need to compile the BMI from module units to object
files and then link the object files. (However, this cannot be done for the BMI
from header units. See the section on :ref:`header units <header-units>` for
more details.
more details.)
BMIs cannot be shipped in an archive to create a module library. Instead, the
BMIs(``*.pcm``) are compiled into object files(``*.o``) and those object files
@ -403,7 +403,7 @@ clang-cl
``clang-cl`` supports the same options as ``clang++`` for modules as detailed above;
there is no need to prefix these options with ``/clang:``. Note that ``cl.exe``
`options to emit/consume IFC files <https://devblogs.microsoft.com/cppblog/using-cpp-modules-in-msvc-from-the-command-line-part-1/>` are *not* supported.
The resultant precompiled modules are also not compatible for use with ``cl.exe``.
The resulting precompiled modules are also not compatible for use with ``cl.exe``.
We recommend that build system authors use the above-mentioned ``clang++`` options with ``clang-cl`` to build modules.
@ -411,7 +411,7 @@ Consistency Requirements
~~~~~~~~~~~~~~~~~~~~~~~~
Modules can be viewed as a kind of cache to speed up compilation. Thus, like
other caching techniques, it is important to maintain cache consistency which
other caching techniques, it is important to maintain cache consistency, which
is why Clang does very strict checking for consistency.
Options consistency
@ -472,8 +472,8 @@ To overcome these requirements and simplify cases like distributed builds and sa
builds, users can use the ``-fmodules-embed-all-files`` flag to embed all input files
into the BMI so that Clang does not need to open the corresponding file on disk.
When the ``-fmodules-embed-all-files`` flag are enabled, Clang explicitly emits the source
code into the BMI file, the contents of the BMI file contain a sufficiently verbose
When the ``-fmodules-embed-all-files`` flag is enabled, Clang explicitly emits the source
code into the BMI file; the BMI file contains a sufficiently verbose
representation to reproduce the original source file.
..[1] Input files: The source files which took part in the compilation of the BMI.
@ -578,7 +578,7 @@ handle the dynamic initialization of non-inline variables in the module unit.
The importable module unit has to emit the initializer even if there is no
dynamic initialization; otherwise, the importer may call a nonexistent
function. The initializer function emits calls to imported modules first
followed by calls to all to of the dynamic initializers in the current module
followed by calls to all of the dynamic initializers in the current module
unit.
Translation units that explicitly or implicitly import a named module must call
@ -689,9 +689,9 @@ ensure it is reachable, e.g. ``using N::g;``.
As of Clang 22.x, the Reduced BMI is enabled by default. You may still want to
use Full BMI with ``-fno-modules-reduced-bmi`` in the following case:
1. Your build system uses two-phase compilation but it haven't adjusted the
1. Your build system uses two-phase compilation, but it hasn't adjusted the
implementation for reduced BMI.
2. You meet a regression with Reduced BMI that you cannot work around. Please
2. You encounter a regression with Reduced BMI that you cannot work around. Please
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
