Windows on armv7 is as alignment tolerant as Linux.
The alignment considerations in the Windows on ARM ABI are documented
at https://docs.microsoft.com/en-us/cpp/build/overview-of-arm-abi-conventions?view=msvc-160#alignment.
The document doesn't explicitly say in which state the OS configures
the SCTLR.A register (and it's not accessible from user space to
inspect), but in practice, unaligned loads/stores do work and seem
to be as fast as aligned loads and stores. (Unaligned strd also does
seem to work, contrary to Linux, but significantly slower, as they're
handled by the kernel - exactly as the document describes.)
Differential Revision: https://reviews.llvm.org/D109960
A function can't be a specification function if it has a dummy procedure
argument, even if it's optional and unused. So don't check the reference
for actual procedure arguments, but rather the characteristics of the
function.
Differential Revision: https://reviews.llvm.org/D109935
From subclause 6.3.3.5: a program unit END statement cannot be
continued in fixed form, and other statements cannot have initial
lines that look like program unit END statements. I think this
is to avoid violating assumptions that are important to legacy
compilers' statement classification routines.
Differential Revision: https://reviews.llvm.org/D109933
Dexter currently accepts two possible arguments to determine the binary
used for testing; either --builder <builder> (and optionally
compiler/linker flags) to build the binary, or --binary <binary> to use
the provided binary directly. If both are passed, then --binary
overrides --builder; if neither are passed, then an error is raised.
This patch instead puts these arguments into a required mutually
exclusive argument group, so that an error is automatically raised by
argparse if both or neither are given.
As an additional change, the --cflags and --ldflags will now raise a
warning if they are passed without the --builder flag, as they are
meaningless if Dexter is using a pre-built binary.
Reviewed By: Orlando
Differential Revision: https://reviews.llvm.org/D109833
Catch invalid attempts to extract the unknowable extent of the last
dimension of an assumed-size array dummy argument, and clean up
problems with assumed-rank arguments in similar circumstances
exposed by testing the fix.
Differential Revision: https://reviews.llvm.org/D109918
A procedure actual argument to a PURE procedure should be required
to have an explicit interface. Implicit-interface actual arguments
to non-PURE procedures remain a warning.
Differential Revision: https://reviews.llvm.org/D109926
Even with all parallel loops reading the output value is still allowed so we
don't have to handle reduction loops differently.
Differential Revision: https://reviews.llvm.org/D109851
Sometimes people intentionally re-define a dylib personlity symbol as a local defined symbol as a workaround to a ld -r bug.
As a result, we could see "too many personalities" to encode. This patch tries to handle this case by ignoring the local symbols entirely.
Differential Revision: https://reviews.llvm.org/D107533
INT, NINT, FLOOR, and CEILING were failing to report overflow as an
error while folding operations with constant operands.
Differential Revision: https://reviews.llvm.org/D109922
The third-party ittnotify sources updated from https://github.com/intel/ittapi.
Changes applied:
- llvm license aded to all files; initial BSD license saved in LICENSE.txt;
- clang-formatted;
- renamed *.c to *.cpp, similar to what we did with all our sources;
- added #include "kmp_config.h" with definition of INTEL_ITTNOTIFY_PREFIX macro
into ittnotify_static.cpp.
Differential Revision: https://reviews.llvm.org/D109333
The intrinsic inquiry functions SIZE and UBOUND -- but not LBOUND --
require a DIM= argument if their first argument is an assumed-size
array. The intrinsic SHAPE must not be used with an assumed-size
array.
Differential Revision: https://reviews.llvm.org/D109912
We can use `OR` instead of `BLEND` if either the element we are not picking is zero (or masked away);
or the element we are picking overwhelms (e.g. it's all-ones) whatever the element we are not picking:
https://alive2.llvm.org/ce/z/RKejao
Reviewed By: RKSimon
Differential Revision: https://reviews.llvm.org/D109726
Silence a bogus error message about an out-of-range DIM= argument
when the argument is assumed-rank. (More generally, don't pretend
to be able to discern a shape of known rank for an assumed-rank
object.)
Differential Revision: https://reviews.llvm.org/D109915
Add the addTileLoopIvsToIndexOpResults method to shift the IndexOp results after tiling.
Reviewed By: nicolasvasilache
Differential Revision: https://reviews.llvm.org/D109761
Validation of the optional generic-spec on an END INTERFACE statement
was missing many possible error cases; reimplement it.
Differential Revision: https://reviews.llvm.org/D109910
Re-add -fexperimental-new-pass-manager to
Clang::CodeGen/pgo-sample-thinlto-summary.c for the test to work on
builds that still default to the old pass manager.
Reviewed By: tejohnson
Differential Revision: https://reviews.llvm.org/D109956
This patch implements the following semantic checks according to
OpenMP Version 5.1 Ordered construct restriction:
```
At most one threads clause can appear on an ordered construct; At most
one simd clause can appear on an ordered construct; At most one
depend(source) clause can appear on an ordered construct; Either
depend(sink:vec) clauses or depend(source) clauses may appear on an
ordered construct, but not both.
```
This patch also implements the following semantic checks according to
the syntax and descriptions in OpenMP Version 5.1 Ordered construct:
```
The dependence types of sink or source are only allowed on an ordered
construct. The depend(*) clauses are not allowed when ordered construct
is a block construct with an ordered region. The threads or simd clauses
are not allowed when the ordered construct is a standalone construct
with no ordered region.
```
Co-authored-by: Sameeran Joshi <sameeranjayant.joshi@amd.com>
Reviewed By: kiranchandramohan
Differential Revision: https://reviews.llvm.org/D108512
Seemingly, names in anonymous namespaces are ALWAYS given the unique
internal linkage name on windows, and I was not aware of this when I put
the names in my test! Replaced them with a wildcard.
Adds support for a feature macro `__opencl_c_read_write_images` 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/D109307
We previously made all multiversioning resolvers/ifuncs have weak
ODR linkage in IR, since we NEED to emit the whole resolver every time
we see a call, but it is not necessarily the place where all the
definitions live.
HOWEVER, when doing so, we neglected the case where the versions have
internal linkage. This patch ensures we do this, so you don't get weird
behavior with static functions.
The MMX pack/unpck shuffles don't need an override - they have the same behaviour as other shuffles (Port0 only).
The SSE pslldq/psrldq shuffles don't need an override - they have the same behaviour as other shuffles (Port0 only).
The SSE pshufb shuffles use 4uops (+1 load).
Noticed the pslldq/psrldq issue while trying to improve reduction costs via the D103695 helper script, and fixed the others while reviewing. Confirmed with Intel AoM / Agner / InstLatX64.
The .machine directive can be used in assembly files to specify the ISA for
the instructions following it.
Review: Ulrich Weigand
Differential Revision: https://reviews.llvm.org/D109660
Rework getConstantstVRegValWithLookThrough in order to make it clear if we
are matching integer/float constant only or any constant(default).
Add helper functions that get DefVReg and APInt/APFloat from constant instr
getIConstantVRegValWithLookThrough: integer constant, only G_CONSTANT
getFConstantVRegValWithLookThrough: float constant, only G_FCONSTANT
getAnyConstantVRegValWithLookThrough: either G_CONSTANT or G_FCONSTANT
Rename getConstantVRegVal and getConstantVRegSExtVal to getIConstantVRegVal
and getIConstantVRegSExtVal. These now only match G_CONSTANT as described
in comment.
Relevant matchers now return both DefVReg and APInt/APFloat.
Replace existing uses of getConstantstVRegValWithLookThrough and
getConstantVRegVal with new helper functions. Any constant match is
only required in:
ConstantFoldBinOp: for constant argument that was bit-cast of float to int
getAArch64VectorSplat: AArch64::G_DUP operands can be any constant
amdgpu select for G_BUILD_VECTOR_TRUNC: operands can be any constant
In other places use integer only constant match.
Differential Revision: https://reviews.llvm.org/D104409
Adds support for a feature macro `__opencl_c_pipes` 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/D109306
thomasraoux