:: (store 1 + 4, addrspace 1)
->
:: (store 1 into undef + 4, addrspace 1)

An offset without a base isn't terribly useful but it's convenient to update
the offset without checking the value. For example, when breaking apart
stores into smaller units

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

Implemented the option to omit Power10 instructions from save stubs via the
option --no-power10-stubs or --power10-stubs=no on lld. --power10-stubs= will
override the other option. --power10-stubs=auto also exists to use the default
behaviour (ie allow Power10 instructions in stubs).

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

This is a compile time optimization for d9e93e8e. Not sure this matters or not, but why not do it just in case.

This does involve querying TLI with a potentially invalid addressing mode for the using instruction, but since we don't actually pass the using instruction to the TLI callback, that should be fine.

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

`tensor_load(tensor_to_memref(x)) -> x` is an incorrect folding because it ignores potential aliasing.

This revision approximates no-aliasing by restricting the folding to occur only when tensor_to_memref
is immediately preceded by tensor_load in the same block. This is a conservative step back towards
correctness until better alias analysis becomes available.

Context: https://llvm.discourse.group/t/properly-using-bufferization-related-passes/2913/6

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

Just to make them easier to find.

Reviewed By: jhenderson

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

This is a compile time optimization for d9e93e8e.  As pointed out in post dommit review on the original review (D96399), there was a moderately large compile time regression with this patch and the eager computation of domtree on matcher construction is the first obvious candidate for why.

[mlir] Add an AccessGroup attribute to load/store LLVM dialect ops and generate the access_group LLVM metadata.

This also includes LLVM dialect ops created from intrinsics.

Reviewed By: ftynse

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

This patch just encapsulates some repeated code.  To do so, it
relocates some functions from interface.cpp to omptarget.cpp.  It also
adjusts them to the LLVM coding style.

This patch is almost NFC except some `DP` messages are a bit
different.  For example, messages like "Entering target region" are
now emitted even if offload is disabled, but a subsequent "Offload is
disabled" is then emitted.

Reviewed By: jdoerfert, grokos

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

Without this patch, an `omp target exit data` before the runtime is
initialized produces a runtime error.  This patch fixes that by
changing `__tgt_target_data_end_mapper` to call `CheckDeviceAndCtors`
like many other runtime routines.

Discussed at
<https://lists.llvm.org/pipermail/openmp-dev/2021-March/003920.html>.

Reviewed By: grokos

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

Without this patch, when the offload device is set to
`omp_get_initial_device()`, the runtime fails with an error diagnostic
when entering target regions or target data regions.

However, OpenMP 5.1, sec. 2.14.5 "target Construct", "Restrictions",
p. 203, L3-5 states:

> The device clause expression must evaluate to a non-negative integer
> value that is less than or equal to the value of
> omp_get_num_devices().

Sec. 3.7.7 "omp_get_initial_device", p. 412, L2-3 states:

> The value of the device number is the value returned by the
> omp_get_num_devices routine.

Similarly, OpenMP 5.0, sec. 2.12.5 "target Construct", "Restrictions",
p. 174 L30-32 states:

> The device clause expression must evaluate to a non-negative integer
> value less than the value of omp_get_num_devices() or to the value
> of omp_get_initial_device().

This patch fixes this behavior by changing the runtime to behave as if
offloading is disabled whenever it finds the offload device (either
from a `device` clause or the default device) is set to the host
device.  In the case of mandatory offloading when
`omp_get_num_devices() == 0`, it incorporates the behavior proposed
for OpenMP 5.2 in OpenMP spec github issue 2669.

Reviewed By: grokos, RaviNarayanaswamy

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

... unless it's a literal

D94640 was a bit too aggressive in its analysis, considering integers
representing valid addresses as invalid. This change rolls back some of
the check, so that only the most obvious case is still flagged.

Before:

```cpp
free((void*)1000);   // literal converted to `void*`: warning good
free((void*)an_int); // `int` object converted to `void*`: warning might
                     //  be a false positive
```

After

```cpp
free((void*)1000);   // literal converted to `void*`: warning good
free((void*)an_int); // doesn't warn
```

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

This reverts commit 293e8fa1.
Breaks build on non-intel hosts, see e.g.
http://45.33.8.238/macm1/4600/step_3.txt

As stated in the CMake manual, we are supposed to use MODULE rules to generate
plugin libraries:

"MODULE libraries are plugins that are not linked into other targets but may be
loaded dynamically at runtime using dlopen-like functionality"

Besides, LLVM's plugin infrastructure fits with the AIX treatment of .so
shared objects more than it fits with the AIX treatment of .a library archives
(which may contain shared objects).

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

https://bugs.llvm.org/show_bug.cgi?id=48918

The bug reported a hang (or very very slow runtime) on a Zen2. Unfortunately, we don't have the hardware right now to debug it and I was not able to reproduce the bug on a HSW.
Theory we've got is that the lbr-checking code could be confused on AMD.

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

For logical or/and reductions we emit regular intrinsics @llvm.vector.reduce.or/and.vxi1 calls.
These intrinsics are not effective for the logical or/and reductions,
especially if the optimizer is able to emit short circuit versions of
the scalar or/and instructions and vector code gets less effective than
the scalar version.
Instead, or reduction for i1 can be represented as:
```
%val = bitcast <ReduxWidth x i1> to iReduxWidth
%res = cmp ne iReduxWidth %val, 0
```
and reduction for i1 can be represented as:
```
%val = bitcast <ReduxWidth x i1> to iReduxWidth
%res = cmp eq iReduxWidth %val, 11111
```
This improves perfromance of the vector code significantly and make it
to outperform short circuit scalar code.

Part of D57059.

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

Patch adds support for passing vector arguments to variadic functions.
Arguments which are fixed shadow GPRs and stack space even when they are
passed in vector registers, while arguments passed through ellipses are
passed in(properly aligned GPRs if available and on the stack once all
GPR arguments registers are consumed.

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

Similar to b3a33553, but this shows a TODO and a potential
miscompile is already present.

We are tracking an FP instruction that does *not* have FMF (reassoc)
properties, so calling that "Unsafe" seems opposite of the common
reading.

I also removed one getter method by rolling the null check into
the access. Further simplification may be possible.

The motivation is to clean up the interactions between FMF and
function-level attributes in these classes and their callers.

The new test shows that there is an existing bug somewhere in
the callers. We assumed that the original code was fully 'fast'
and so we produced IR with 'fast' even though it was just 'reassoc'.

If the file in line directive does not exist on the system we need, to
use the original file to get its file id.

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

The aim is to add missing non-posix functions for z/OS libc++ (strtod_l and strtof_l).

Reviewed By: #libc, ldionne

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

This reverts commit bf5a5826.
Also depends on now-reverted 4c8fb7dd

This reverts commit 4112299e.
Seems to depend on 4c8fb7dd which
is being reverted.

This reverts commit 4c8fb7dd.
Breaks check-llvm everywhere, see https://reviews.llvm.org/D96122

Reviewed By: antiagainst

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

Commit 5856f202
by Mikhail Dvorskiy, 02/13/2021 08:28 PM
parent f515ca89

Iterator types renaming: ForwardIterator -> RandomAccessIterator; for parallel patterns/bricks

https://reviews.llvm.org/D96266

Add a folder to rewrite a sequence such as:

```
   %t1 = ...
   %v = vector.transfer_read %t0[%c0...], {masked = [false...]} :
     tensor<static_sizesxf32>, vector<static_sizesxf32>
  %t2 = vector.transfer_write %v, %t1[%c0...] {masked = [false...]} :
     vector<static_sizesxf32>, tensor<static_sizesxf32>
```

into:

```
   %t0
```

The producer of t1 may or may not be DCE'd depending on whether it is a
block argument or has side effects.

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

The SwitchStmt::FirstCase member is not initialized when the AST is
built by the ASTStmtReader. See the below code of
ASTStmtReader::VisitSwitchStmt in the case where the for loop does not
have any iterations:
```
    // ... more code ...
    SwitchCase *PrevSC = nullptr;
    for (auto E = Record.size(); Record.getIdx() != E; ) {
      SwitchCase *SC = Record.getSwitchCaseWithID(Record.readInt());
      if (PrevSC)
        PrevSC->setNextSwitchCase(SC);
      else
        S->setSwitchCaseList(SC); // Sets FirstCase !!!

      PrevSC = SC;
    }
  } // return
```
Later, in ASTNodeImporter::VisitSwitchStmt,
we have a condition that depends on this uninited value:
```
  for (SwitchCase *SC = S->getSwitchCaseList(); SC != nullptr;
       SC = SC->getNextSwitchCase()) {
       // ... more code ...
  }

```
This is clearly an UB. This causes non-deterministic crashes when
ClangSA analyzes some code with CTU. See the below report by valgrind
(the whole valgrind output is attached):
```
==31019== Conditional jump or move depends on uninitialised value(s)
==31019==    at 0x12ED1983: clang::ASTNodeImporter::VisitSwitchStmt(clang::SwitchStmt*) (ASTImporter.cpp:6195)
==31019==    by 0x12F1D509: clang::StmtVisitorBase<std::add_pointer, clang::ASTNodeImporter, llvm::Expected<clang::Stmt*>>::Visit(clang::Stmt*) (StmtNodes.inc:591)
==31019==    by 0x12EE4FDF: clang::ASTImporter::Import(clang::Stmt*) (ASTImporter.cpp:8484)
==31019==    by 0x12F09498: llvm::Expected<clang::Stmt*> clang::ASTNodeImporter::import<clang::Stmt>(clang::Stmt*) (ASTImporter.cpp:164)
==31019==    by 0x12F3A1F5: llvm::Error clang::ASTNodeImporter::ImportArrayChecked<clang::Stmt**, clang::Stmt**>(clang::Stmt**, clang::Stmt**, clang::Stmt**) (ASTImporter.cpp:653)
==31019==    by 0x12F13152: llvm::Error clang::ASTNodeImporter::ImportContainerChecked<llvm::iterator_range<clang::Stmt**>, llvm::SmallVector<clang::Stmt*, 8u> >(llvm::iterator_range<clang::Stmt**> const&, llvm::SmallVector<clang::Stmt*, 8u>&) (ASTImporter.cpp:669)
==31019==    by 0x12ED099F: clang::ASTNodeImporter::VisitCompoundStmt(clang::CompoundStmt*) (ASTImporter.cpp:6077)
==31019==    by 0x12F1CC2D: clang::StmtVisitorBase<std::add_pointer, clang::ASTNodeImporter, llvm::Expected<clang::Stmt*>>::Visit(clang::Stmt*) (StmtNodes.inc:73)
==31019==    by 0x12EE4FDF: clang::ASTImporter::Import(clang::Stmt*) (ASTImporter.cpp:8484)
==31019==    by 0x12F09498: llvm::Expected<clang::Stmt*> clang::ASTNodeImporter::import<clang::Stmt>(clang::Stmt*) (ASTImporter.cpp:164)
==31019==    by 0x12F13275: clang::Stmt* clang::ASTNodeImporter::importChecked<clang::Stmt*>(llvm::Error&, clang::Stmt* const&) (ASTImporter.cpp:197)
==31019==    by 0x12ED0CE6: clang::ASTNodeImporter::VisitCaseStmt(clang::CaseStmt*) (ASTImporter.cpp:6098)
```

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

RegBankSelect creates zext and trunc when it selects banks for uniform i1.
Add zext_trunc_fold from generic combiner to post RegBankSelect combiner.

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

Combine zext(trunc x) to x when truncated bits are known to be zero.

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

For vectors we consider a bit as known if it is the same for all demanded
vector elements (all elements by default). KnownBits BitWidth for vector
type is size of vector element. Add support for G_BUILD_VECTOR.
This allows combines of urem_pow2_to_mask in pre-legalizer combiner.

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

Revert "[Coverage] Emit gap region between statements if first statements contains terminate statements."

This reverts commit 2d7374a0.
Breaks ContinuousSyncMode/basic.c in check-profile on macOS.

We are tracking an FP instruction that does *not* have FMF (reassoc)
properties, so calling that "Unsafe" seems opposite of the common
reading.

I also removed one getter method by rolling the null check into
the access. Further simplification seems possible.

The motivation is to clean up the interactions between FMF and
function-level attributes in these classes and their callers.

CodeGenPrepare currently first removes empty blocks, then in a loop
performs other optimizations. One of those optimizations is the removal
of call instructions that invoke @llvm.assume, which can create new
empty blocks.

This means that when a branch only contains a call to __builtin_assume(),
the empty branch will survive into MIR, and will then only be
half-removed by MIR-level optimizations (e.g. removing the branch but
leaving the condition intact).

Fix it by eliminating @llvm.expect builtin calls before removing empty
blocks.

Reviewed By: bkramer

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

We have a plugin.process.gdb-remote.packet-timeout setting, which can be
used to control how long the lldb client is willing to wait before
declaring the server side dead. Our test suite makes use of this
feature, and sets the setting value fairly high, as the low default
value can cause flaky tests, particularly on slower bots.

After fixing TestPlatformConnect (one of the few tests exercising the
remote platform capabilities of lldb) in 4b284b9c, it immediately
started being flaky on the arm bots. It turns out this is because the
packet-timeout setting is not being applied to platform connections.

This patch makes the platform connections also respect the value of this
setting. It also adds a test which checks that the timeout value is
being honored.

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

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

Add support for the following Fortran dialect options:
  - -default*
  - -flarge-sizes

It also adds two test cases:
  # For checking whether `flang-new` is passing options correctly to `flang-new -fc1`.
  # For checking if `fdefault-` arguments are processed properly.

Also moves the Dialect related option parsing to a dedicated function
and adds a member `defaultKinds()` to `CompilerInvocation`

Depends on: D96032

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

This patch is a large number of small changes that should hopefully not
affect the generated machine code but are still important to get right
so that the machine verifier won't complain about them.

The llvm/test/CodeGen/AVR/pseudo/*.mir changes are also necessary
because without the liveins the used registers are considered undefined
by the machine verifier and it will complain about them.

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

Reviewed By: rjmccall

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