The 'init' clause allows an interop-modifier of prefer_type(list) and
and interop-types 'target' and 'targetsync'.
The 'append_args' clause uses an append-op that also includes
interop-types ('target' and 'targetsync') and will allow
a prefer_type list in the next OpenMP version.
This change adds a helper struct OMPInteropInfo and uses it in the parsing
of both the 'init' and 'append_args' clauses.
One OMPInteropInfo object represents the info in a single 'init' clause.
Since 'append_args' allows a variable number of interop items it will
require an array of OMPInteropInfo objects once that is supported.
Differential Revision: https://reviews.llvm.org/D132171
Using Max for both "PIC Level" and "PIE Level" is inconsistent. PIC imposes less
restriction while PIE imposes more restriction. The result generally
picks the more restrictive behavior: Min for PIC.
This choice matches `ld -r`: a non-pic object and a pic object merge into a
result which should be treated as non-pic.
To allow linking "PIC Level" using Error/Max from old bitcode files, upgrade
Error/Max to Min.
Reviewed By: tejohnson
Differential Revision: https://reviews.llvm.org/D130531
The previous implementation translated from names like sifive-7-series
to sifive-7-rv32 or sifive-7-rv64. This also required sifive-7-rv32
and sifive-7-rv64 to be valid CPU names. As those are not real
CPUs it doesn't make sense to accept them in -mcpu.
This patch does away with the translation and adds sifive-7-series
directly to RISCV.td. Removing sifive-7-rv32 and sifive-7-rv64.
sifive-7-series is only allowed in -mtune.
I've also added "rocket" to RISCV.td but have not removed rocket-rv32
or rocket-rv64.
To prevent -mcpu=sifive-7-series or -mcpu=rocket being used with llc,
I've added a Feature32Bit to all rv32 CPUs. And made it an error to
have an rv32 triple without Feature32Bit. sifive-7-series and rocket
do not have Feature32Bit or Feature64Bit set so the user would need
to provide -mattr=+32bit or -mattr=+64bit along with the -mcpu to
avoid the error.
SiFive no longer names their newer products with 3, 5, or 7 series.
Instead we have p200 series, x200 series, p500 series, and p600 series.
Following the previous behavior would require a sifive-p500-rv32 and
sifive-p500-rv64 in order to support -mtune=sifive-p500-series. There
is currently no p500 product, but it could start getting confusing if
there was in the future.
I'm open to hearing alternatives for how to achieve my main goal
of removing sifive-7-rv32/rv64 as a CPU name.
Reviewed By: reames
Differential Revision: https://reviews.llvm.org/D131708
Formatted input allows for an empty numeric input field, which
signifies a zero value, but list-directed and NAMELIST input does
not -- apart from the special case of a NAMELIST array.
Differential Revision: https://reviews.llvm.org/D132178
The runtime I/O library correctly handles endianness conversions on payload
data I/O and on the output of sequential record headers and footers, but
does not swap endianness when required when reading sequential record headers
and footers back in for READ and BACKSPACE statements. Mea culpa. Fix.
Fixes https://github.com/llvm/llvm-project/issues/57126
Differential Revision: https://reviews.llvm.org/D132168
A character array can be used as a format in an I/O data transfer
statement, with the interpretation that its elements are concatenated
in element order to constitute the format.
Support in the runtime with an extra optional descriptor argument
to six I/O API calls; support in semantics by removing an earlier
check for a simply contiguous array presented as a format.
Some work needs to be done in lowering to pass a character array
descriptor to the I/O runtime API when present
Differential Revision: https://reviews.llvm.org/D132167
This patch introduces the priority analysis and the priority advisor,
the default implementation, and the scaffolding for introducing the
other implementations of the advisor.
Reviewed By: mtrofin
Differential Revision: https://reviews.llvm.org/D131220
The MOLD= argument to NULL() is allowed to be a null pointer itself --
for example, NULL(MOLD=NULL(MOLD=...)) should not raise spurious semantic
errors.
Differential Revision: https://reviews.llvm.org/D132166
Emit a "Assignment to procedure 'foo' is not allowed" error message
for more cases of 'foo' than just declaraed subprograms, rather than
assuming that those additional cases were named constants.
Differential Revision: https://reviews.llvm.org/D132165
f18 unconditionally uses a scaling algorithm for complex/complex division
that avoids needless overflows and underflows when computing the sum of
the squares of the components of the denominator -- but testing has shown
some 1 ULP differences relative to the naive calculation due to the
extra operations and roundings. So use the scaling algorithm only when
the naive calculation actually would overflow or underflow.
Differential Revision: https://reviews.llvm.org/D132164
When a particular module name has been brought into a compilation
as an intrinsic module via USE,INTRINSIC, perhaps indirectly via
an enclosing USE statement, f18 will resolve later USE statements
to it unless they are USE,NON_INTRINSIC. This is not entirely
correct -- a bare USE statement for a module name that happens to
match that of an intrinsic module should still search the search
paths for a non-intrinsic module file of the same name.
Differential Revision: https://reviews.llvm.org/D132163
When checking function interface compatibility for procedure pointer
assignment/initialization or actual/dummy procedure association, don't
emit a diagnositic about function result shape incompatibility unless
the interfaces differ in rank or have distinct constant extents on a
dimension. Function results whose dimensions are determined by dummy
arguments or host-associated variables are not necessarily incompatible.
Differential Revision: https://reviews.llvm.org/D132162
Assignment statements need to check for array shape conformance
errors that are discernable at compilation time.
Differential Revision: https://reviews.llvm.org/D132161
In the case of a data transfer I/O statement with an illegal unit number and
error recovery, ensure that data transfer API calls don't raise internal
errors due to the I/O statement representation unexpectedly being something
other than a data transfer statement.
Differential Revision: https://reviews.llvm.org/D132160
A literal % character in an error message needs to be doubled
so that it appears in the output of snprintf().
Differential Revision: https://reviews.llvm.org/D132158
While a NAMELIST input group item for an array can have fewer
values than expected, or none, an input group item for a scalar
must have a value.
Differential Revision: https://reviews.llvm.org/D132157
CharacterExtremumAccumulator::GetResult() needs to use byte counts, not wide
character counts, when calling memcpy() & memset().
Differential Revision: https://reviews.llvm.org/D132156
The intrinsic function SPACING() was being folded to the smallest
normal number (TINY(x)) rather than to a smaller subnormal result
when that result really was subnormal.
Differential Revision: https://reviews.llvm.org/D132155
Support these legacy extension intrinsic functions with unambiguous
semantics in those existing compilers that support them by means
of recognizing them as aliases for standard intrinsics (IMAG) or
with simple rewrites (IZEXT, JZEXT). Note that ZEXT has different
semantics in different existing compilers, so we will not support it
due to lack of a broad unambiguous precedent.
Differential Revision: https://reviews.llvm.org/D132154
(~A | C) | (A ^ B) --> ~(A & B) | C
https://alive2.llvm.org/ce/z/Qw3aiJ
This extends the existing fold (just above the new match)
to peek through another 'or' instruction.
This should let the motivating case from issue #57174
simplify completely.
Use `std::clamp` directly from the standard library now that LLVM is built with
C++17 standards mode.
Differential Revision: https://reviews.llvm.org/D131869
The DXC driver tests don't really belong mixed in with the toolchain
tests. This pulls them out to their own file and moves the
SimpleDiagnosticConsumer into a header so it can be used by both DXC and
toolchain tests.
fast-forwarded.
This avoids deprecation warning:
```
warning: definition of implicit copy assignment operator for 'AddrInfo'
is deprecated because it has a user-declared copy constructor
[-Wdeprecated-copy]
```
This fixes https://github.com/llvm/llvm-project/issues/57229
When we ship LLVM 16, <ranges> won't be considered experimental anymore.
We might as well do this sooner rather than later.
Differential Revision: https://reviews.llvm.org/D132151
A debug message in `LoopAccessAnalysis` did not have a newline in it, causing printed debug messages to be formatted incorrectly.
Reviewed By: craig.topper
Differential Revision: https://reviews.llvm.org/D132172
When checking if we are cross-compiling, use `CMAKE_HOST_SYSTEM_NAME`
rather than `CMAKE_HOST_SYSTEM` which seems to have the full version
number attached.
Reviewed By: smeenai
Differential Revision: https://reviews.llvm.org/D132130
On known hardware, reductions, gather, and scatter operations have execution latencies which correlated with the vector length (VL) of the operation. Most other operations (e.g. simply arithmetic) don't correlated in this way, and instead essentially fixed cost as VL varies.
When I'd implemented initial scalable cost model support for reductions, gather, and scatter operations, I had used an upper bound on the statically unknown VL. The argument at the time was that this prevented falsely low costs, and biased the vectorizer away from generating bad (on some hardware) code. Unfortunately, practical experience shows we were a bit too effective at that goal, and the high costs defacto prevents vectorization using these constructs at all.
This patch reverses course, and ties the returned cost not to the maximum possible VL, but the VL which would correspond to VScaleForTuning. This parameter is the same one the vectorizer uses when normalizing loop costs, so the term effectively cancels out. The result is that the vectorizer now sees these constructs as comparable in cost to their fixed length variants.
This does introduce the possibility of the cost for these operations being a significant under estimate on platforms where actual VLEN is far from that implied by VScaleForTuning. On such platforms, we might make poor heuristic choices. Probably not in LV itself (due to the cancellation mentioned above), but possibly during e.g. lowering. I'm not currently aware of any concrete examples of this, but this patch does open a concern which did not previously exist.
Previously, we had the problem of overestimating costs causing the same problem on machines much closer to default values for vscale for tuning. With this patch, we still have that problem potentially if vscale for tuning is set high (manually), and then the code is run on a narrow VLEN machine.
Differential Revision: https://reviews.llvm.org/D131519
This patch adds OMPIRBuilder support for the safelen clause for the
simd directive.
Reviewed By: shraiysh, Meinersbur
Differential Revision: https://reviews.llvm.org/D131526
We held off on this before as `LLVM_LIBDIR_SUFFIX` conflicted with it.
Now we return this.
`LLVM_LIBDIR_SUFFIX` is kept as a deprecated way to set
`CMAKE_INSTALL_LIBDIR`. The other `*_LIBDIR_SUFFIX` are just removed
entirely.
I imagine this is too potentially-breaking to make LLVM 15. That's fine.
I have a more minimal version of this in the disto (NixOS) patches for
LLVM 15 (like previous versions). This more expansive version I will
test harder after the release is cut.
Reviewed By: sebastian-ne, ldionne, #libc, #libc_abi
Differential Revision: https://reviews.llvm.org/D130586
The methods to perform such operations have been implemented for the DynamicMemRefType in a way that is similar to the implementation for StridedMemRefType. Up until here one could pass an unranked memref to the library, and thus obtain a “dynamic” memref descriptor, but then there would have been no possibility to operate on its content.
to match the emitted warning, which has changed. I push this without
review as it is a one-line NFC. I have discussed it in D130386, which
altered the warning in question.
Add the clang option -finline-max-stacksize=<N> to suppress inlining
of functions whose stack size exceeds the given value.
Reviewed By: aeubanks
Differential Revision: https://reviews.llvm.org/D131986
This patch "modernizes" the implementation of these operations by
switching them to assembly formats and type inference traits.
Reviewed By: rriddle
Differential Revision: https://reviews.llvm.org/D131971
Mike Rice