This patch restricts the argument of performSymbolicEvaluation to an Instruction
and simplifies the code accordingly.
Differential Revision: https://reviews.llvm.org/D156994
`print` functions require `FILE` and `stdout` to be available and cause
compilation errors on platforms that don't support the file system.
Differential Revision: https://reviews.llvm.org/D156585
Make it a multichoice string to closer mirror the CMake variable. This
allows writing `UNSUPPORTED: libcpp-hardening-mode=unchecked` rather
than `UNSUPPORTED: !libcpp-has-hardened-mode && !libcpp-has-debug-mode`.
Differential Revision: https://reviews.llvm.org/D155906
The last use was removed by:
commit b1f41685a60e5416af8f636393bffd03ac4c13f5
Author: Alexandros Lamprineas <alexandros.lamprineas@arm.com>
Date: Thu Jun 1 15:09:08 2023 +0100
These flags are redundant since everything in the `cl_Group`
explicitly sets flags anyway. Remove the Flags because they're
confusing and will cause problems with some later refactorings.
The following restrictions for USE_DEVICE_PTR and USE_DEVICE_ADDR clauses on OMP TARGET DATA directive are implemented in this patch.
- A list item may not be specified more than once in use_device_ptr clauses that appear on the directive.
- A list item may not be specified more than once in use_device_addr clauses that appear on the directive.
- A list item may not be specified in both a use_device_addr clause and a use_device_ptr clause on the directive.
- A list item that appears in a use_device_ptr or use_device_addr clause must not be a structure element.
- A list item that appears in a use_device_ptr must be of type C_PTR.
Reviewed By: kiranchandramohan
Differential Revision: https://reviews.llvm.org/D155133
This patch makes use of the infrastructure established in D157046 to speed up computation of the canonical context hash in the dependency scanner. This is somewhat hot code, since it's ran for all modules in the dependency graph of every TU.
I also tried an alternative approach that tried to avoid allocations as much as possible (essentially doing `HashBuilder.add(Arg.toStringRef(ArgVec))`), but that turned out to be slower than approach in this patch.
Note that this is not problematic in the same way command-line hashing used to be prior D143027. The lambda is now being called even for constant strings.
Depends on D157046.
Reviewed By: benlangmuir
Differential Revision: https://reviews.llvm.org/D157052
This patch makes use of the infrastructure established in D157046 to avoid needless allocations via `StringSaver`.
Depends on D157046.
Reviewed By: benlangmuir
Differential Revision: https://reviews.llvm.org/D157048
This patch abstracts away the string allocation and vector push-back from command line generation. Instead, **all** generated arguments are passed into `ArgumentConsumer`, which may choose to do the string allocation and vector push-back, or something else entirely.
Reviewed By: benlangmuir
Differential Revision: https://reviews.llvm.org/D157046
so that they lead to an error when compiled for non-x86 targets.
Follow-up to D151590.
```
% aarch64-linux-gnu-gcc -c -mavx a.c
aarch64-linux-gnu-gcc: error: unrecognized command-line option ‘-mavx’
% clang --target=aarch64-unknown-linux-gnu -c -mavx a.c # without this patch
clang: warning: argument unused during compilation: '-mavx' [-Wunused-command-line-argument]
...
% clang --target=aarch64-unknown-linux-gnu -c -mavx a.c # with this patch
clang: error: unsupported option '-mavx' for target 'aarch64-unknown-linux-gnu'
```
As a workaround for https://github.com/llvm/llvm-project/issues/63270, we don't
report an error for -msse4.2.
Reviewed By: pengfei, skan
Differential Revision: https://reviews.llvm.org/D156962
There is no `threadDim` in CUDA. Instead, it is `blockDim`. Then the current
`blockDim` is `gridDim` in CUDA.
Reviewed By: jhuber6
Differential Revision: https://reviews.llvm.org/D157051
This patch fixes the issue that multiple definition of kernel environment global
variables can occur because of wrong linkage.
Fixes#64284.
Reviewed By: jhuber6
Differential Revision: https://reviews.llvm.org/D156955
this PR tries to match the following pattern, seperate from D156881
```
%vscale = call i64 @llvm.vscale.i64()
%shift = shl nuw nsw i64 %vscale, 11
```
Now, we only check the shl recursively when the OrZero is true.
Reviewed By: goldstein.w.n
Differential Revision: https://reviews.llvm.org/D157062
`__dynamic_cast` relies on `type_info`, which its signature assumed to be in the generic / default address space. This patch corrects the oversight (we know that `type_info` resides in the GlobalVar address space) and adds an associated test.
Reviewed By: yaxunl
Differential Revision: https://reviews.llvm.org/D155870
`atomic_compare_exchange` was using `_strong` and `memory_order_acquire`
by default. This is not aligned with general use, for example, in C++,
the default is `memory_order_seq_cst`. To reduce the ambiguity, make the
version and ordering explicitly.
Reviewed By: cferris
Differential Revision: https://reviews.llvm.org/D156952
This will make it possible to accept the spelling as `StringLiteral` in D157029 and avoid some unnecessary allocations in a later patch.
Reviewed By: benlangmuir
Differential Revision: https://reviews.llvm.org/D157035
The last dependency of code defined in LoopVectorize.cpp has been
removed a while ago. Move VPTransformState::get() to VPlan.cpp where
other members are also defined.
OpInterface inheritance will duplicate base interfaces, causing compilation failure. Unique the set of base interfaces.
Reviewed By: rriddle, jdd
Differential Revision: https://reviews.llvm.org/D156964
Summary:
In cases where the PC has no function name, lldb-vscode crashes.
`lldb::SBFrame::GetDisplayFunctionName()` returns a `nullptr`, and when we
attempt to construct an `std::string`, it raises an exception.
Test plan:
This can be observed with creating a test file (credit to @clayborg for
the example):
```
int main() {
typedef void (*FooCallback)();
FooCallback foo_callback = (FooCallback)0;
foo_callback(); // Crash at zero!
return 0;
}
```
and attempting to debug the file through VSCode.
I add a test case in D156732 which should cover this.
Differential Revision: https://reviews.llvm.org/D156970
The copyprivate clause is not yet implemented. Provide a TODO
error message when this clause is seen.
Reviewed By: NimishMishra
Differential Revision: https://reviews.llvm.org/D155596
Tweak the immediate on two vror.vi test cases to use a uimm6 immediate
that would have failed before D156974 when we were looking for a simm6
immediate.
The `Twine::str()` function currently always allocates heap memory via `std::string`. However, some instances of `Twine` don't need an intermediate buffer at all, and the rest can attempt to print into a stack buffer first.
This is intentionally not making use of `Twine::isSingleStringLiteral()` from D157010 to skip saving the string in the bump-pointer allocator, since the `StringSaver` documentation suggests that MUST happen for every given string.
Reviewed By: benlangmuir
Differential Revision: https://reviews.llvm.org/D157015
Since GCC 11, the bundled Solaris/SPARC GCC uses the `sparcv8plus`
subdirectory for 32-bit objects, just like upstream GCC. Before that, it
used `32` instead from a local patch.
Since `clang` doesn't know about that `sparcv8plus` subdirectory, it
wouldn't properly use GCC 11+ installations.
The new `solaris-sparc-gcc-search.test` testcase wasn't run initially (like
the existing `crash-report-null.test`) because the `.test` suffix wasn't
handled.
Tested on `sparcv9-sun-solaris2.11`, `amd64-pc-solaris2.11`, and
`x86_64-pc-linux-gnu`.
Differential Revision: https://reviews.llvm.org/D157013
The `const char *` storage backing StringLiteral has static lifetime. Making `Twine` aware of that allows us to avoid allocating heap memory in some contexts (e.g. avoid passing it to `StringSaver::save()` in a follow-up Clang patch).
Reviewed By: benlangmuir
Differential Revision: https://reviews.llvm.org/D157010
Fixed a bug where when Skelton CU had DW_AT_ranges, it the output CU DW_AT_ranges
offset was relative, and not absolute.
Reviewed By: maksfb
Differential Revision: https://reviews.llvm.org/D156958
Now that we have new DWARF Rewriter we can remove DW_AT_low_pc when converting
DW_AT_low_pc/DW_AT_high_pc to DW_AT_ranges. Which closer follows DWARF spec.
Leaving CU DW_AT_low_pc in place. Reading the spec I think it's needed.
Reviewed By: maksfb
Differential Revision: https://reviews.llvm.org/D156957
Also rename the flag from supportsBackwardScavenger to
eliminateFrameIndicesBackwards to reflect what it actually does.
X86 is the only target still using forwards frame index elimination.
This will not block removing support for forwards register scavenging,
because X86 does not use the register scavenger.
Differential Revision: https://reviews.llvm.org/D156983
This regressed in D154458 due to the added tracking of used variable
names that now also has to be cleared alongside the counter.
Reviewed By: rafaelubalmw, c-rhodes, awarzynski
Differential Revision: https://reviews.llvm.org/D156547
