Always read bitcode according to the -opaque-pointers mode. Do not
perform auto-detection to implicitly switch to typed pointers.

This is a step towards removing typed pointer support, and also
eliminates the class of problems where linking may fail if a typed
pointer module is loaded before an opaque pointer module. (The
latest place where this was encountered is D139924, but this has
previously been fixed in other places doing bitcode linking as well.)

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

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

This new function was added in b72f1ec9,
but wasn't exported from the DLL on Windows.

This fixes the parallel/omp_parallel_if.c OpenMP testcase on
Windows.

If testing for a warning option like -Wno-<foo> with GCC, GCC won't
print any diagnostic at all, leading to the options being accepted
incorrectly. However later, if compiling a file that actually prints
another warning, GCC will also print warnings about these -Wno-<foo>
options being unrecognized.

This avoids warning spam like this, for every OpenMP source file that
produces build warnings with GCC:

    cc1plus: warning: unrecognized command line option ‘-Wno-int-to-void-pointer-cast’
    cc1plus: warning: unrecognized command line option ‘-Wno-return-type-c-linkage’
    cc1plus: warning: unrecognized command line option ‘-Wno-covered-switch-default’
    cc1plus: warning: unrecognized command line option ‘-Wno-enum-constexpr-conversion’

This matches how such warning options are detected and added in
llvm/cmake/modules/HandleLLVMOptions.cmake, e.g. like this:

    check_cxx_compiler_flag("-Wclass-memaccess" CXX_SUPPORTS_CLASS_MEMACCESS_FLAG)
    append_if(CXX_SUPPORTS_CLASS_MEMACCESS_FLAG "-Wno-class-memaccess" CMAKE_CXX_FLAGS)

This also matches how LLDB warning options were restructured for
GCC compatibility in e546bbfd.

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

This covers 128-bit loads, and atomicrmw operations without a single native
instruction. Using CAS saves has a better chance of succeeding with high
contention on some systems.

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

This reverts commit 3c9f479a.
Breaks tests on macOS, see e.g. https://reviews.llvm.org/D139980#3993989

This refactors out the offset and address operand pattern matching into
a ComplexPattern, so that one pattern fragment can match the dynamic and
static (offset) addresses in all possible positions.

Split out from D139530, which also contained an improvement to global
address folding.

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

Fixes constant-folding infinite loop reported by @uabelho on rG5ca77541

Without this change this function could return nullptr if no further
transformation took place making InstCombine pass incorrectly report no
IR changes preventing analyses invalidation.

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

To preserve test intent, remove a pointer indirection and use
a GEP instead of bitcast, so the type is still mentioned.

Use FoldID to cache SignExtendExprs that get folded to a different
SCEV.

Depends on D137505.

Reviewed By: mkazantsev

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

To preserve test intent, drop the pointer type.

now with the fixed warning and updated lit tests
---
[RISC-V][HWASAN] Add support for HWASAN code instrumentation for RISC-V

Reviewed By: vitalybuka

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

All the pointer-indirected cases are no longer relevant with
opaque pointers. To preserve at least some of the test intent,
switch to by value passing of the unnamed types. Otherwise we
wouldn't be testing anything at all.

The tensor operands do not bufferize to a memory read.

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

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

This helps avoid issues on non-BWI targets which can end up splitting the shuffles to 2 x 256-bit bitshifts of a smaller scalar width

To preserve test intent, remove the pointer types and replace by
value types, otherwise this wouldn't be testing anything at all.

On macOS, hardcoding the path of bash leads to a failure in executing
update_core_linalg_named_ops.sh, due to an old version of bash being
present in that location.

Signed-off-by: Ramkumar Ramachandra <r@artagnon.com>

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

This patch changes the `test-lower-to-llvm` pass into a named pipeline.
The functionality is unchanged but thanks to this change, we don't have
to pull the dependencies of all the passes that this pass calls.
In other words, `TestLowerToLLVMPass::getDependDialects` was supposed to
transitively declare all the dialects that were used in the union of all
the invoked passes.

NFC

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

This reverts commit 492c4718.

As pointed out by nloped, the transform in f2 is not correct: If
%shr is poison, then freeze may result in a negative value. The
transform is correct in the case where the freeze is pushed through
the operation in a way that guarantees the result is non-negative,
which is the case I had tested.

Handle the case where the lo/hi subvectors are a split load.

(dup (load) z_or_x_passthrough) => (replicating load)

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

Temporarily add expectedToStdOptional to llvm/Support/Error.h for migration.

I found that this information is helpful when using this tool.

Reviewed By: kadircet

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

The revision adds an inbounds attribute to the LLVM dialect
GEP operation. It extends the builders and the import and export
to support the optional inbounds attribute.

As all builders set inbounds to false by default, existing lowerings
from higher-level dialects to LLVM dialect are not affected by the
change. Canonicalization/folding remains untouched since it currently
does not implement any simplifications in case of undefined behavior
(the handling of undefined behavior is deferred to LLVM).

Reviewed By: ftynse

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

The recently introduced iterative constant import
(https://reviews.llvm.org/D137559) fails for programs that
subsequently import constant expressions with duplicate
subexpressions. The reason is a broken duplicate check
in getConstantsToConvert. The revision fixes the bug and
adds a test case that imports two constant expressions
with duplicates.

Reviewed By: ftynse

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

This adds basic HADD and RHADD support for SVE, by marking the AVGFLOOR
and AVGCEIL as custom and converting those to HADD_PRED/RHADD_PRED
AArch64 nodes. Both the existing intrinsics and the _PRED nodes are then
lowered to the _ZPmZ instructions.

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

This reverts commit f1f1b60c.

Temporary revert, possibly triggers a new assertion failure on
QualType::getCommonPtr.
We're working on a reproducer, to follow-up on
https://reviews.llvm.org/D136554.

The checker applies constraints in a sequence and adds new nodes for these states.
If a constraint violation is found this sequence should be stopped with a sink
(error) node. Instead the `generateErrorNode` did add a new error node as a new
branch that is parallel to the other node sequence, the other branch was not
stopped and analysis was continuing on that invalid branch.
To add an error node after any previous node a new version of `generateErrorNode`
is needed, this function is added here and used by `StdLibraryFunctionsChecker`.
The added test executes a situation where the checker adds a number of
constraints before it finds a constraint violation.

Reviewed By: NoQ

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

SCR1 is available at https://github.com/syntacore/scr1

'syntacore-scr1-base' corresponds to SCR1_CFG_RV32IC_BASE,
'syntacore-scr1-max' corresponds to SCR1_CFG_RV32IMC_MAX.

SCR1_CFG_RV32EC_MIN is RV32EC, which is currently unsupported.

Reviewed By: craig.topper

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

This is part of an effort to migrate from llvm::Optional to
std::optional:

https://discourse.llvm.org/t/deprecating-llvm-optional-x-hasvalue-getvalue-getvalueor/63716