SimplifyDemandedBits can turn srl into sra if the bits being shifted
in aren't demanded. This patch can recover the original sra in some cases.
I've renamed the tablegen class for detecting W users since the "overflowing operator"
term I originally borrowed from Operator.h does not include srl.
Reviewed By: luismarques
Differential Revision: https://reviews.llvm.org/D109162
This patch removes globals from the lldCOFF library, by moving globals
into a context class (COFFLinkingContext) and passing it around wherever
it's needed.
See https://lists.llvm.org/pipermail/llvm-dev/2021-June/151184.html for
context about removing globals from LLD.
I also haven't moved the `driver` or `config` variables yet.
Differential Revision: https://reviews.llvm.org/D109634
In https://reviews.llvm.org/D100481, forceful inline of all non-kernel
functions using lds was disabled since AMDGPULowerModuleLDS pass now handles
static lds. However that pass does not handle extern lds so non-kernel
functions using extern lds must sill be inline.
Reviewed By: hsmhsm, arsenm
Differential Revision: https://reviews.llvm.org/D109773
This makes some tests in vector-reductions-logical.ll more stable when
applying D108837.
The cost of branching is higher when vector ops are involved due to
potential SLP transformations.
Reviewed By: spatel
Differential Revision: https://reviews.llvm.org/D108935
Turn on `use-context-cost-for-preinliner` to use context-sensitive byte size cost for preinliner decisions by default.
This is a more accurate proxy of inline cost than profile size. We tested on our large workload that it delivers measureable CPU improvement.
Differential Revision: https://reviews.llvm.org/D109893
We are having issues running the integration test of the sparse compiler
on AArch64 (crashing in the lib). This revision adds more assertions.
Reviewed By: jsetoain
Differential Revision: https://reviews.llvm.org/D109861
This patch supports construct trait set selector by using the existed
declare variant infrastructure inside `OMPContext` and simd selector is
currently not supported. The goal of this patch is to pass the declare variant
test inside sollve test suite.
Reviewed By: jdoerfert
Differential Revision: https://reviews.llvm.org/D109635
This way, we do not need to set LLVM_CMAKE_PATH to LLVM_CMAKE_DIR when (NOT LLVM_CONFIG_FOUND)
Reviewed By: #libc, ldionne
Differential Revision: https://reviews.llvm.org/D107717
When `libcxx` or `libcxxabi` is built with `-DLLVM_USE_SANITIZER=MemoryWithOrigins`
**and** `-DLIBCXX[ABI]_USE_COMPILER_RT=ON`, all of the `LIBCXX[ABI]_SUPPORTS_*_FLAG`
checks fail, since the value of `CMAKE_REQUIRED_FLAGS` is not set correctly.
Bugzilla: https://bugs.llvm.org/show_bug.cgi?id=51774
Reviewed By: #libc, #libc_abi, compnerd, ldionne
Differential Revision: https://reviews.llvm.org/D109342
Specify the C and C++ standards explicitly for this test. This avoids
failures for drivers that default to older standards.
Differential Revision: https://reviews.llvm.org/D109857
Summary:
Introduce a new frontend flag `-fswift-async-fp={auto|always|never}`
that controls how code generation sets the Swift extended async frame
info bit. There are three possibilities:
* `auto`: which determines how to set the bit based on deployment target, either
statically or dynamically via `swift_async_extendedFramePointerFlags`.
* `always`: default, always set the bit statically, regardless of deployment
target.
* `never`: never set the bit, regardless of deployment target.
Differential Revision: https://reviews.llvm.org/D109451
Don't create a useless functional patch with only filename in it when
there is only include directives to be patched but they're not
requested.
Differential Revision: https://reviews.llvm.org/D109880
Storing the vtable field of an object should use the same address space as
the this pointer. Currently it is assumed to be addr space 0 but this may not
be true.
This assumption (added in 054cc3b1b4) caused
issues for the out-of-tree CHERI targets.
Reviewed by: John McCall, Alexander Richardson
Differential Revision: https://reviews.llvm.org/D109841
Don't install clang-tidy checks and IncludeFixer or process clang diags
when they're going to be dropped. Also disables analysis for some
warnings completely.
Differential Revision: https://reviews.llvm.org/D109884
This patch increases the expected line number for one of the checks so that it doesn't have to be updated for any added/removed lines in the RUN section.
This change is in preparation for the following patch: https://reviews.llvm.org/D109060
Reviewed By: jsji
Differential Revision: https://reviews.llvm.org/D109541
Introduce a new command-line flag `-swift-async-fp={auto|always|never}`
that controls how code generation sets the Swift extended async frame
info bit. There are three possibilities:
* `auto`: which determines how to set the bit based on deployment target, either
statically or dynamically via `swift_async_extendedFramePointerFlags`.
* `always`: the default, always set the bit statically, regardless of deployment
target.
* `never`: never set the bit, regardless of deployment target.
Patch by Doug Gregor <dgregor@apple.com>
Reviewed By: doug.gregor
Differential Revision: https://reviews.llvm.org/D109392
Summary:
add a new API seek for the Cursor class in the DataExtractor.cpp
Reviewers: James Henderson, Fangrui Song
Differential Revision: https://reviews.llvm.org/D109603
Remove the previous error and add support for special handling of small
complex types as in PPC64 ELF ABI. As in, generate code to load from
varargs location and pack it in a temp variable, then return a pointer to
the struct.
Reviewed By: sfertile
Differential Revision: https://reviews.llvm.org/D106393
Change the asan-module pass into a MODULE_PASS_WITH_PARAMS in the
pass registry, and add a single parameter called 'kernel' that
can be set instead of having a special pass name 'kasan-module'
to trigger that special pass config.
Main reason is to make sure that we have a unique mapping from
ClassName to PassName in the new passmanager framework, making it
possible to correctly identify the passes when dealing with options
such as -print-after and -print-pipeline-passes.
This is a follow-up to D105006 and D105007.
Split ThreadSanitizerPass into ThreadSanitizerPass (as a function
pass) and ModuleThreadSanitizerPass (as a module pass).
Main reason is to make sure that we have a unique mapping from
ClassName to PassName in the new passmanager framework, making it
possible to correctly identify the passes when dealing with options
such as -print-after and -print-pipeline-passes.
This is a follow-up to D105006 and D105007.
Split MemorySanitizerPass into MemorySanitizerPass (as a function
pass) and ModuleMemorySanitizerPass (as a module pass).
Main reason is to make sure that we have a unique mapping from
ClassName to PassName in the new passmanager framework, making it
possible to correctly identify the passes when dealing with options
such as -print-after and -print-pipeline-passes.
This is a follow-up to D105006 and D105007.
Recently a vulnerability issue is found in the implementation of VLLDM
instruction in the Arm Cortex-M33, Cortex-M35P and Cortex-M55. If the
VLLDM instruction is abandoned due to an exception when it is partially
completed, it is possible for subsequent non-secure handler to access
and modify the partial restored register values. This vulnerability is
identified as CVE-2021-35465.
The mitigation sequence varies between v8-m and v8.1-m as follows:
v8-m.main
---------
mrs r5, control
tst r5, #8 /* CONTROL_S.SFPA */
it ne
.inst.w 0xeeb00a40 /* vmovne s0, s0 */
1:
vlldm sp /* Lazy restore of d0-d16 and FPSCR. */
v8.1-m.main
-----------
vscclrm {vpr} /* Clear VPR. */
vlldm sp /* Lazy restore of d0-d16 and FPSCR. */
More details on
developer.arm.com/support/arm-security-updates/vlldm-instruction-security-vulnerability
Differential Revision: https://reviews.llvm.org/D109157
When expanding the non-secure call instruction we are emiting code
to clear the secure floating-point registers only if the targeted
architecture has floating-point support. The potential problem is
when the source code containing non-secure calls are built with
-mfloat-abi=soft but some other part of the system has been built
with -mfloat-abi=softfp (soft and softfp are compatible as they use
the same procedure calling standard). In this case floating-point
registers could leak to non-secure state as the non-secure won't
have cleared them assuming no floating point has been used.
Differential Revision: https://reviews.llvm.org/D109153
Adds support for macro `__opencl_c_program_scope_global_variables`
in C++ for OpenCL 2021 enabling a respective optional core feature
from OpenCL 3.0.
This change aims to achieve compatibility between C++ for OpenCL
2021 and OpenCL 3.0.
Differential Revision: https://reviews.llvm.org/D109305
D109708 added "DIA SDK" to our win sysroot for hermetic builds
that use LLVM_ENABLE_DIA_SDK. But the build system still has to
manually pass flags pointing to it.
Since we have a /winsysroot flag, make it look at DIA SDK in
the sysroot.
With this, the following is enough to compile the DIA2Dump example:
out\gn\bin\clang-cl ^
"sysroot\DIA SDK\Samples\DIA2Dump\DIA2Dump.cpp" ^
"sysroot\DIA SDK\Samples\DIA2Dump\PrintSymbol.cpp" ^
"sysroot\DIA SDK\Samples\DIA2Dump\regs.cpp" ^
/diasdkdir "sysroot\DIA SDK" ^
ole32.lib oleaut32.lib diaguids.lib
Differential Revision: https://reviews.llvm.org/D109828
lit.util.which('link') picks up the wrong link.exe in git bash, leading
to this error:
# command stderr:
/usr/bin/link: extra operand '/LIBPATH:C:\\Progra....'
Try '/usr/bin/link --help' for more information.
Instead, assume that link.exe is next to cl.exe.
Differential Revision: https://reviews.llvm.org/D109832
Alias the "sp" register to "x31" on AArch64 if one is present and does
not have the alt_name. This is the case when connecting to gdbserver.
Differential Revision: https://reviews.llvm.org/D109695
I am working on a target in a downstream LLVM repo, and it seems that if a target backend chooses to disable loop unrolling this test would fail. A solution would be to modify the test to search for a different string instead.
The specific test checks for `if.true.direct_targ` which appears in the output when thinlto is not used (ie samplepgo). The same is true for `if.false.orig_indirect`.
However, if a target disables loop unrolling in the backend, the test fails as `if.true.direct_targ` no longer appears, though `if.false.orig_indirect` still does. This can be seen by using a clang pragma to disable loop unrolling in the `unroll()` function.
For reference, the following files are the outputs of the last 2 test functions being compiled as the test case does, with and without thinlto, and with and without loop unrolling on the latest x86 clang build. The loop unrolling pragma was used to simulate the loop unrolling being disabled in a backend.
```
// RUN: %clang_cc1 -O2 -fprofile-sample-use=%S/Inputs/pgo-sample-thinlto-summary.prof %s -emit-llvm -o out.ll
// RUN: %clang_cc1 -O2 -fprofile-sample-use=%S/Inputs/pgo-sample-thinlto-summary.prof %s -emit-llvm -flto=thin -o out.ll
```
Reviewed By: tejohnson
Differential Revision: https://reviews.llvm.org/D109234
Remove the name and alt_name parameters from AddRegister() and instead
pass them via RegisterInfo.name and .alt_name fields. This makes
the API simpler and removes some duplication.
Differential Revision: https://reviews.llvm.org/D109872
Adding trackExpressionValue to the checker so it tracks the value of the
implicit cast's DeclRefExpression up to initialization/assignment. This
way the report becomes cleaner.
Differential Revision: https://reviews.llvm.org/D109836
instead of a pointer. There are just two callers of this function, and
both of them have a valid target pointer, so there's no need for all
implementations to concern themselves with whether the pointer is null.
Craig Topper