The Clang compiler generates internal functions for OpenMP. Current
patch marks these functions as artificial.

Reviewed By: aprantl

Differential Revision: https://reviews.llvm.org/D111521

This extends the handling of uniform memory operations to handle the case where a store is storing a loop invariant value. Unlike the general case of a store to an invariant address where we must use the last active lane, in this case we can use any lane since all lanes must produce the same result.

For context, the basic structure of the existing code and how the change fits in:
* First, we select a widening strategy. (The result is irrelevant for this patch.)
* Then we determine if a computation is uniform within all lanes of VF. (Note this is the uniform-per-part definition, not LAI's uniform across all unrolled iterations definition.)
* If it is, we overrule the widening strategy, and unconditionally scalarize.
* VPReplicationRecipe - which is what actually does the scalarization - knows how to handle unform-per-part values including for scalable vectors. However, we do need to know that the expression is safe to execute without predication - e.g. the uniform mem op was unconditional in the original loop. (This part was split off and already landed.)

An obvious question is why not simply implement the generic case? The answer is that I'm going to, but doing so without a canonicalization towards uniform causes regressions due to bad interaction with scalarization/uniformity of values feeding the uniform mem-op. This patch is needed to avoid those regressions.

Differential Revision: https://reviews.llvm.org/D130364

This supports checks in C1801-C1805 for derived type with BIND attribute.
The other compilers such as 'gfortran' and 'ifort' do not report error
for C1802 and C1805, so emit warnings for them.

Reviewed By: klausler

Differential Revision: https://reviews.llvm.org/D130438

The semantic checks and runtime have been supported. This supports the
lowering of intrinsic ABORT.

`gfortran` prints a backtrace before abort, unless `-fno-backtrace` is
given. This is good to use. The intrinsic BACKTRACE is not supported
yet, so add TODO in the runtime.

This extention is needed in SPEC2017 521.wrf_r in
https://github.com/llvm/llvm-project/issues/55955.

Reviewed By: klausler

Differential Revision: https://reviews.llvm.org/D130439

As Fortran 2018 18.2.3.6, the intrinsic `c_loc(x)` gets the C address
of argument `x`. It returns the scalar of type C_PTR. As defined in
iso_c_binding in `flang/module/__fortran_builtins.f90`, C_PTR is the
derived type with only one component of integer 64.

This supports the lowering of intrinsic module procedure `c_loc` by
converting the address of argument into integer 64, where the argument
is lowered as Box and the address is generated using fir.box_addr.

The lowering of intrinsic `c_funloc` has the similar characteristic and
will be supported later.

The execution tests for various data types are in issue
https://github.com/llvm/llvm-project/issues/56552.

Reviewed By: Jean Perier

Differential Revision: https://reviews.llvm.org/D129659

The problem Alexander reported on D127982 was caused by an optimization
for AVX512-FP16 instruction. We must limit it to the feature enabled only.

During the investigation, I found we didn't expand for fp_round/fp_extend
without F16C. This may result runtime crash, so change them too.

Reviewed By: RKSimon

Differential Revision: https://reviews.llvm.org/D130817

s/true/ArchSpec::ExactMatch
s/false/ArchSpec::CompatibleMatch

Differential Revision: https://reviews.llvm.org/D121290

I went over the output of the following mess of a command:

`(ulimit -m 2000000; ulimit -v 2000000; git ls-files -z | parallel --xargs -0 cat | aspell list --mode=none --ignore-case | grep -E '^[A-Za-z][a-z]*$' | sort | uniq -c | sort -n | grep -vE '.{25}' | aspell pipe -W3 | grep : | cut -d' ' -f2 | less)`

and proceeded to spend a few days looking at it to find probable typos
and fixed a few hundred of them in all of the llvm project (note, the
ones I found are not anywhere near all of them, but it seems like a
good start).

Differential Revision: https://reviews.llvm.org/D130982

This reverts commit 0cc3c184.

The changes did not account for templated code where one instantiation
may trigger the diagnostic but other instantiations will not, as in:
```
template <int I, class T>
void foo(int x) {
    bool b1 = (x & sizeof(T)) == 8;
    bool b2 = (x & I) == 8;
    bool b3 = (x & 4) == 8;
}

void run(int x) {
    foo<4, int>(8);
}
```

If you're having trouble getting a yaml2obj macro expansion to do what
you want, it's useful to be able to print the output of the
preprocessing to see what your macros expanded to //before// going
into the YAML processing phase.

yaml2obj has its own preprocessing system which isn't the same as any
other well-known thing like cpp. So there's no way to do this macro
expansion via another tool: yaml2obj will have to do it itself.

In this commit I add an `-E` flag to yaml2obj to do that.

Differential Revision: https://reviews.llvm.org/D130981

Add a new IRBuilderBase::CreateIntrinsic which takes the return type and
argument values for the intrinsic call but does not take an explicit
list of types to mangle. Instead the builder works this out from the
intrinsic declaration and the types of the supplied arguments.

This means that the mangling is hidden from the client, which in turn
means that intrinsic definitions can change which arguments are mangled
without requiring any changes to the client code.

Differential Revision: https://reviews.llvm.org/D130776

This folds a v4i32 Mul(And(Srl(X, 15), 0x10001), 0xffff) into a v8i16
CMLTz instruction. The Srl and And extract the top bit (whether the
input is negative) and the Mul sets all values in the i16 half to all
1/0 depending on if that top bit was set. This is equivalent to a v8i16
CMLTz instruction. The same applies to other sizes with equivalent
constants.

Differential Revision: https://reviews.llvm.org/D130874

TestInlineStepping.py is flaky while TestUseSourceCache.py fails on
Windows 11 only. Marked them skipped to make buildbot happy.

This patch adds constant folder for TanhOp which only supports single and double precision floating-point.

Differential Revision: https://reviews.llvm.org/D130960

Multiple top-level MLIR documents did not have a table of contents tag,
making them harder to nagivate.

Reviewed By: #libc, philnik, Mordante

Spies: Mordante, jloser, philnik, libcxx-commits

Differential Revision: https://reviews.llvm.org/D130785

I went over the output of the following mess of a command:

`(ulimit -m 2000000; ulimit -v 2000000; git ls-files -z | parallel --xargs -0 cat | aspell list --mode=none --ignore-case | grep -E '^[A-Za-z][a-z]*$' | sort | uniq -c | sort -n | grep -vE '.{25}' | aspell pipe -W3 | grep : | cut -d' ' -f2 | less)`

and proceeded to spend a few days looking at it to find probable typos
and fixed a few hundred of them in all of the llvm project (note, the
ones I found are not anywhere near all of them, but it seems like a
good start).

Reviewed By: #libc, philnik

Spies: philnik, libcxx-commits, mgorny, arichardson

Differential Revision: https://reviews.llvm.org/D130905

[DAG] matchRotateSub - ensure the (pre-extended) shift amount is wide enough for the amount mask (PR56859)

matchRotateSub is given shift amounts that will already have stripped any/zero-extend nodes from - so make sure those values are wide enough to take a mask.

Currently, FlangOptionsDocs.td doesn't specify `ExcludedFlags` which
means that in the generated documentation file we expose flags that:
  * we don't necessarily won't to advertise to our users (e.g. hidden flags), or
  * are not supported altogether (e.g. CL options).
This patch defines `ExcludeFlags` to fix that. The definition of
`ExcludeFlags` was copied from Clang so that LLVM frontends have
consistent documentation.

It might be a bit counter-intuitive that IncludeFlags alone is not
sufficient here. However, the current logic in ClangOptionDocEmitter.cpp
will parse IncludeFlags and print all options that contains one of the
included flags, as well as their aliases. So, for example, for -fopenmp
(which is a supported Flang option), one would also get /fopenmp (i.e.
CL mode equivalent for -fopenmp). By adding ExcludeFlags, we make sure
that such aliases are excluded.

I've also taken the liberty and moved FlangOptionsDocs.td. Originally it
was located in Flang's "flang/include" directory, but there shouldn't be
any implementation/documentation files there. Instead, I'm moving it to
the "flang/docs" directory.

Differential Revision: https://reviews.llvm.org/D130558

In SmallVector header we use couple of times exactly same enable_if,
in this change we de-duplicate it and declare only once.

Extracted from: https://reviews.llvm.org/D129990

Differential Revision: https://reviews.llvm.org/D130779

This allows the tests to also pass when compiled in opt mode.

If we have interleave groups in the loop we want to vectorise then
we should fall back on normal vectorisation with a scalar epilogue. In
such cases when tail-folding is enabled we'll almost certainly go on to
create vplans with very high costs for all vector VFs and fall back on
VF=1 anyway. This is likely to be worse than if we'd just used an
unpredicated vector loop in the first place.

Once the vectoriser has proper support for analysing all the costs
for each combination of VF and vectorisation style, then we should
be able to remove this.

Added an extra test here:

  Transforms/LoopVectorize/AArch64/sve-tail-folding-option.ll

Differential Revision: https://reviews.llvm.org/D128342

[RISCV][NFCI] Set TransientStackAlignment and rely on it rather than RVV-specific logic on RVV-less functions

* TargetFrameLowering has a TransientStackAlignment field that "returns
  the number of bytes to which the stack pointer must be aligned at all
  times, even between calls.
  * As explained in the [RISC-V calling
    convention](https://github.com/riscv-non-isa/riscv-elf-psabi-doc/blob/master/riscv-cc.adoc),
    the stack pointer must remain fully aligned throughout execution for
    compliant code. This is important for embedded targets that might avoid
    realigning the stack pointer for interrupt service routines. Systems
    running full OSes may always realign the stack anyway.
* TransientStackAlignment is used in estimateStackSize in
  MachineFrameInfo and in PEI::calculateFrameObjectOffsets.
  * estimateStackSize is only used in the RISC-V backend for scavenging
    slots. It may be possible to craft a function where the difference
    is observable, but it wouldn't be a meaningful test.
  * calculateFrameObjectOffsets makes use of TransientStackAlignment,
    but then sets the stack alignment to the max of that alignment and
    MaxAlign, which is unconditionally set to 16 in
    RISCVFrameLowering::processFunctionBeforeFrameFinalized
  * I've changed this logic to only set MaxAlign if there are RVV frame
    objects. There should be no functional change here for either RVV
    targets (MaxAlign is set as before) or non-RVV targets
    (TransientStackAlign is now 16 anyway).

Differential Revision: https://reviews.llvm.org/D130068

The CPU is used to determine which inline asm instructions are allowed, so
needs to be copied across in case the outlined function contains any.

Reviewed By: asb

Differential Revision: https://reviews.llvm.org/D130687

This fixes warnings like these:

../runtime/src/kmp_dispatch.cpp:2159:24: warning: left operand of comma operator has no effect [-Wunused-value]
    OMPT_LOOP_DISPATCH(*p_lb, *p_ub, pr->u.p.st, status);
                       ^~~~~
../runtime/src/kmp_dispatch.cpp:2159:31: warning: left operand of comma operator has no effect [-Wunused-value]
    OMPT_LOOP_DISPATCH(*p_lb, *p_ub, pr->u.p.st, status);
                              ^~~~~
../runtime/src/kmp_dispatch.cpp:2159:46: warning: left operand of comma operator has no effect [-Wunused-value]
    OMPT_LOOP_DISPATCH(*p_lb, *p_ub, pr->u.p.st, status);
                                     ~~~~~~~ ^~
../runtime/src/kmp_dispatch.cpp:2159:50: warning: expression result unused [-Wunused-value]
    OMPT_LOOP_DISPATCH(*p_lb, *p_ub, pr->u.p.st, status);
                                                 ^~~~~~

Now the API getExtendedAddReductionCost is used to determine the cost of extended Add reduction with optional Mul. For Arm, it could cover the cases. But for other target, for example: RISCV, they support other kinds of extended recution, such as FAdd.

This patch does the following changes:
1, Split getExtendedAddReductionCost into 2 new API: getExtendedReductionCost which handles the extended reduction with addtional input of Opcode; getMulAccReductionCost which handle the MLA cases the getExtendedAddReductionCost.
2, Refactor getReductionPatternCost, add some contraint condition to make sure the getMulAccReductionCost should only handle the reuction of Add + Mul.

Differential Revision: https://reviews.llvm.org/D130868

When the mlir-tblgen tool is set up, the `MLIR_TABLEGEN_EXE` variable
is set, which either points to the mlir-tblgen tool built in the current
cmake build, or points to one built in a nested cmake build (if cross
conpiling, or if building with e.g. `LLVM_OPTIMIZED_TABLEGEN`.

The `MLIR_TABLEGEN_EXE` variable is only set within the scope of the
mlir/CMakeLists.txt file, so it's unavailable in sibling level projects
such as flang.

Set the `MLIR_TABLEGEN_EXE` and the `MLIR_TABLEGEN_TARGET` variables
as global, so that flang can use them properly without guessing.

Differential Revision: https://reviews.llvm.org/D130350

If CMAKE_CROSSCOMPILING, then the newly built flang-new executable was
cross compiled and thus can't be executed on the build system, and thus
can't be used for generating module files.

Differential Revision: https://reviews.llvm.org/D130349

CMAKE_DL_LIBS is documented as "Name of library containing dlopen
and dlclose".

On Windows platforms, there's no system provided dlopen/dlclose, but
it can be argued that if you really intend to call dlopen/dlclose,
you're going to be using a third party compat library like
https://github.com/dlfcn-win32/dlfcn-win32, and CMAKE_DL_LIBS should
expand to its name.

This has been argued upstream in CMake in
https://gitlab.kitware.com/cmake/cmake/-/issues/17600 and
https://gitlab.kitware.com/cmake/cmake/-/merge_requests/1642, that
CMAKE_DL_LIBS should expand to "dl" on mingw platforms.

The merge request wasn't merged though, as it caused some amount of
breakage, but in practice, Fedora still carries a custom CMake patch
with the same effect.

Thus, this patch fixes cross compiling OpenMP for mingw targets
on Fedora with their custom-patched CMake.

Differential Revision: https://reviews.llvm.org/D130892

Supporting something like `-fxray-instruction-threshold= 1` is not intended.

Introduced in D130356, reported here:
https://reviews.llvm.org/rG7ac7ec820296#inline-7690