Enable llvm-driver for:
llvm-dwp
llvm-libtoo-darwin
sancov

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

Detect and process INCLUDE lines that are guarded by OpenMP conditional
compilation markers (!$), when enabled.

Fixes https://github.com/llvm/llvm-project/issues/64128.

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

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

More Wconversion and Wno-sign-conversion warning fixes.

Reviewed By: lntue

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

Folding of LBOUND/UBOUND on assumed-rank arrays could lead to bogus errors
later.  This is a regression from a recent change intended to ensure that
patently bad DIM= arguments were caught even in the case of assumed-rank.
Rearrange the order of checks so that those bad DIM= argument values are
caught but otherwise defer LBOUND/UBOUND of assumed-rank arguments to
run time.  (It was tempting to always fold LBOUND(ar,DIM=n) to 1, but
that would obscure the run time error required when 'n' is out of bounds,
including the case of a scalar 'ar'.)

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

Running lit tests on Windows can fail because its use of
`os.path.realpath` expands substitute drives, which are used to keep
paths short and avoid hitting MAX_PATH limitations.

Changes lit logic to:

Use `os.path.abspath` on Windows, where `MAX_PATH` is a concern that we
can work around using substitute drives, which `os.path.realpath` would
resolve.

Use `os.path.realpath` on Unix, where the current directory always has
symlinks resolved, so it is impossible to preserve symlinks in the
presence of relative paths, and so we must make sure that all code paths
use real paths.

Also updates clang's `FileManager::getCanonicalName` and `ExtractAPI`
code to avoid resolving substitute drives (i.e. resolving to a path
under a different root).

How tested: built with `-DLLVM_ENABLE_PROJECTS=clang` and built `check-all` on both Windows

Differential Revision: https://reviews.llvm.org/D154130
Reviewed By: @benlangmuir

Patch by Tristan Labelle <tristan@thebrowser.company>!

Add test coverage for truncating selects for D149903.

I decided to clean up the CMake files as well.
Only FotranEvaluate directly needs quadmath, so we only need
to link these two together.

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

At the moment the IRInterpreter will stop interpreting an expression
after a hardcoded 4096 instructions. After it reaches the limit it will
stop interpreting and leave the process in whatever state it was when
the timeout was reached.

This patch changes the instruction limit to a timeout and uses the
user-specified expression timeout value for this. The main motivation is
to allow users on targets where we can't use the JIT to run more
complicated expressions if they really want to (which they can do now by
just increasing the timeout).

The time-based approach also seems much more meaningful than the
arbitrary (and very low) instruction limit. 4096 instructions can be
interpreted in a few microseconds on some setups but might take much
longer if we have a slow connection to the target. I don't think any
user actually cares about the number of instructions that are executed
but only about the time they are willing to wait for a result.

Based off an original patch by Raphael Isemann.

Differential revision: https://reviews.llvm.org/D102762

Reapplying after revert due to sanitizer failure.  Includes fix to avoid querying dead lanes for vreg introduced by previous transform.

The code was written with the implicit assumption that each IMPLICIT_DEF either a) the tied operand, or b) an untied source, but not both. This is true right now, but an upcoming change may allow CSE of IMPLICIT_DEFs in some cases, so let's rewrite the code to handle that possibility.

I added an MIR case which demonstrates the multiple use IMPLICIT_DEF. To my knowledge, this is not a reachable configuration from IR right now.

As an aside, this makes the structure a much closer match with the sub-reg liveness case, and we can probably just merge these routines. (Future work.)

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

As noted by Craig, we can improve codegen for the -1 case as well.

Benchmark results:
```
----------------------------------------------------------------
Benchmark                                    old             new
----------------------------------------------------------------
bm_vector_bool_ranges_find/1             5.64 ns         6.08 ns
bm_vector_bool_ranges_find/2             16.5 ns         6.03 ns
bm_vector_bool_ranges_find/3             20.3 ns         6.07 ns
bm_vector_bool_ranges_find/4             22.2 ns         6.08 ns
bm_vector_bool_ranges_find/5             23.5 ns         6.05 ns
bm_vector_bool_ranges_find/6             24.4 ns         6.10 ns
bm_vector_bool_ranges_find/7             26.7 ns         6.10 ns
bm_vector_bool_ranges_find/8             25.0 ns         6.08 ns
bm_vector_bool_ranges_find/16            27.9 ns         6.07 ns
bm_vector_bool_ranges_find/64            44.5 ns         5.35 ns
bm_vector_bool_ranges_find/512            243 ns         25.7 ns
bm_vector_bool_ranges_find/4096          1858 ns         35.6 ns
bm_vector_bool_ranges_find/32768        15461 ns         93.5 ns
bm_vector_bool_ranges_find/262144      126462 ns          571 ns
bm_vector_bool_ranges_find/1048576     497736 ns         2272 ns
```

Reviewed By: #libc, Mordante

Spies: var-const, Mordante, libcxx-commits

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

Three APIs of the runtime support library are not used by lowering
and were never implemented.  Delete them from their header file.

This patch fixes the return time for sched_getscheduler which was set to
always zero. The syscall documentation, however, defines:

On success, sched_getscheduler() returns the policy for the thread (a
nonnegative integer).

I also changed the return type for sched_setscheduler, but this change
didn't impact and test case.

This patch also removes the duplicated code from param_and_scheduler_test.cpp
and adds SCHED_BATCH and SCHED_IDLE to the tests.

Reviewed By: michaelrj

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

I believe the help text for the flag `--offload-host-device` is wrong. Currently, the help text says "Only compile for the offloading host." but the flag alias with `--cuda-compile-host-device` which
has the help text "Compile CUDA code for both host and device (default). Has no effect on non-CUDA compilations."

Fixes https://github.com/llvm/llvm-project/issues/64243

Reviewed By: jdoerfert

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

We used to convert them to M1 types in arguments and return
value, which causes failures in CodeGen since it is not legal
to insert subvectors with LMUL>1 to M1 vectors.

Fixes 64266

Reviewed By: craig.topper

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

Reviewed By: nikic

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

I noticed these were missing.

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

Work through several issues with LBOUND() and UBOUND() of ASSOCIATE
construct entities that have been associated with named constants or
subobjects of named constants that are sporting non-default lower bounds.
Sometimes the non-default lower bounds matter, sometimes they don't.
Add a fairly exhaustive test to work through the possibilities.

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

Using the nonans FMF and the DAG.isKnownNeverNaN on the inputs.

Reviewed By: fakepaper56

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

In a8097201 I refactored some logic to
deal with the clang resource directory in standalone LLDB builds.
However, this logic escaped me because it only runs when you do not
build LLDB.framework.

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

This issue was raised on https://github.com/llvm/llvm-project/issues/64268.

`flang/lib/Optimizer/Transforms/SimplifyIntrinsics.cpp` includes
`flang/Optimizer/HLFIR/HLFIRDialect.h` and might fails if the HLFIR related
tablegen files have not been generated.

Reviewed By: vzakhari

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

DPROD(x,y) is defined as DBLE(x)*DBLE(y) and that's exactly how
the implementation of its rewriting and possible folding should
be implemented, instead of the current code that only works when
both arguments are scalar and crashes otherwise.

Fixes https://github.com/llvm/llvm-project/issues/63991.

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

An implied DO loop in an array constructor may not have a type (explicit
or otherwise) with a character length that depends on a value of an
implied DO index or a non-constant expression if the implied DO loop
executes no iterations.  When the iteration count can be known to be
zero at compilation time, catch the case of a non-constant length
expression correctly.

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

Reviewed By: jpienaar, gflegar

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

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

This is a quick-fix to get the CI green again, not a proper solution.

Consider the following piece of code:

```
void innermost_loop(int i, double d1, double d2, double delta, int n, double cells[n])
{
  int j;
  const double d1d = d1 * delta;
  const double d2d = d2 * delta;

  for (j = 0; j <= i; j++)
    cells[j] = d1d * cells[j + 1] + d2d * cells[j];
}
```

When compiling at -Ofast level, after the "Reassociate expressions"
pass, this code is transformed into an equivalent of:

```
  int j;

  for (j = 0; j <= i; j++)
    cells[j] = (d1 * cells[j + 1] + d2 * cells[j]) * delta;
```

Effectively, the computation of those loop invariants isn't done
before the loop anymore, we have one extra multiplication on each
loop iteration instead. Sadly, this results in a significant
performance hit.

Similarly, specifically crafted user code will also experience
inability to hoist those invariants.

This patch is solving this issue by adding the ability to undo such
reassociation into the LICM pass. Note that for doing such
transformation this pass requires the same conditions as the
"Reassociate expressions" pass, namely, the involved binary operators
must have the reassociations allowed (e.g. by specifying the `fast`
attribute) and they must have single use only.

Some parts of this patch were suggested by Nikita Popov.

Reviewed By: huntergr, nikic, paulwalker-arm

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

[Transforms][LICM] A test case for the upcoming fix D152281 for the issue with reassociation profitability

This commit introduces a test for the upcoming change addressing
the following issue: https://github.com/llvm/llvm-project/issues/62736

Reviewed By: qcolombet

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

I made this change hastily to fix a bot and failed to cormat the code
correctly.

HIP allows __fp16 as function arguments and return value by passing
-fallow-half-arguments-and-returns to clang through hipcc.

https://reviews.llvm.org/D133885 removed -fallow-half-arguments-and-returns
and add a TargetInfo member to control it.

This caused regressions in some HIP apps
(https://github.com/ROCm-Developer-Tools/HIP/issues/3178).

Reviewed by: Artem Belevich

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

Fixes: https://github.com/ROCm-Developer-Tools/HIP/issues/3178

Currently, only `SUB`, `ADD`, `OR` and `XOR` are covered. This patch
adds `AND`, `SHL`, `SRA`, `SRL`.

Reviewed By: craig.topper
Differential Revision: https://reviews.llvm.org/D155344

[bazel] typo fix for f0549017 [mlir][bufferization][transform][python] Add enums to bindings & mixins

This reverts commit 245ec675.

Recommits eea92586 with a fix to only erase the instruction from the
first part if it is defined outside the loop. This fixes a
use-after-free error reported.

Loop index variables are privatised for a worksharing loop.
The alloca ops of the privatised index are hoisted to the
entry block of the outlineable region or parent function.
With HLFIR, the hlfir.declare should be created in the same
place as the alloca op. To achieve this the alloc and the
hflir.declare should be created in the same place. A new
function is created in OpenMP.cpp for this purpose.

Reviewed By: tblah

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

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

<https://github.com/llvm/llvm-project/issues/64090>

A forthcoming patch addresses these cases.