Summary: Modifies all checks that are language version dependent to use `isLanguageVersionSupported`

Reviewers: jdoerfert, lebedev.ri, aaron.ballman, gribozavr2, Eugene.Zelenko

Reviewed By: gribozavr2

Subscribers: wuzish, nemanjai, xazax.hun, hiraditya, kbarton, steven_wu, dexonsmith, arphaman, lebedev.ri, cfe-commits

Tags: #clang

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

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

[DAGCombiner][X86] Improve narrowExtractedVectorLoad to handle cases where the element size isn't byte sized by the subvector is.

Summary:
Follow up from D75377. If the subvector is byte sized and the
index is aligned to the subvector size, we can shrink the load.

Reviewers: spatel, RKSimon

Reviewed By: RKSimon

Subscribers: dbabokin, hiraditya, llvm-commits

Tags: #llvm

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

The build_vector needs to be the only user of the data, but the
chain will likely have another use. So we can't make sure the
build_vector is the only user of the node.

The expected output is erroneous and will be corrected alongside a fix
to ensure stack arguments are widened to register width before writing
to the parameter save area.

MLIR ExecutionEngine and derived tools (e.g., mlir-cpu-runner) would trigger an
assertion inside ORC JIT while ExecutionEngine is being destructed after a
failed linking due to a missing function definition. The reason for this is the
JIT lookup that may return an Error referring to strings stored internally by
the JIT. If the Error outlives the ExecutionEngine, it would want have a
dangling reference, which is currently caught by an assertion inside JIT thanks
to hand-rolled reference counting. Rewrap the error message into a string
before returning.

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

Some attribute kinds are not supported as "value" attributes of
`llvm.mlir.constant` when translating to LLVM IR. We were correctly reporting
an error, but continuing the translation using an "undef" value instead,
leading to a surprising mix of error messages and output IR. Abort the
translation after the error is reported.

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

On SystemZ there are a set of "access registers" that can be copied in and
out of 32-bit GPRs with special instructions. These instructions can only
perform the copy using low 32-bit parts of the 64-bit GPRs. However, the
default register class for 32-bit integers is GRX32, which also contains the
high 32-bit part registers.

In order to never end up with a case of such a COPY into a high reg, this
patch adds a new simple pre-RA pass that selects such COPYs into target
instructions.

This pass also handles COPYs from CC (Condition Code register), and COPYs to
CC can now also be emitted from a high reg in copyPhysReg().

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

Review: Ulrich Weigand.

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

While we have some tests for this command already, they are very vague.
This is not surprising -- it's hard to make strict assertions about the
assembly if your input is a c++ source file. This means that the tests
can more-or-less only detect when the command breaks completely, and not
when there is a subtle change in meaning due to e.g. a code refactor --
which is something that I am getting ready to do.

This tests in this patch create binaries with well known data (via assembler
and yaml2obj). This means that we are able to make precise assertions
about the text that lldb is supposed to print. As some of the features
of this command are only available with a real process, I use a minidump
core file to create a sufficiently realistic process object.

Summary:
The argument that sets the prefetch type of a prefetch intrinsic must
be an immediate value.

Reviewers: andwar, sdesmalen, efriedma

Subscribers: tschuett, hiraditya, rkruppe, psnobl, llvm-commits

Tags: #llvm

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

Use MIOperand in collectLocalKilledOperands to make the search
global, as we already have to search for global uses too. This
allows us to delete more dead code when tail predicating.

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

This prepares for propagating versions through the server so diagnostics
etc can be versioned.

In RDA, check against the already decided dead instructions when
looking at users. This allows an instruction to be removed if it
has multiple users, but they're all dead.

This means that IT instructions can be considered killed once all
the itstate using instructions are dead.

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

[AIX][XCOFF] Fix XCOFFObjectWriter assertion failure with alignment-related gap and improve text section output testing

SUMMARY:
1.if there is a gap between the end virtual address of one section and the beginning virtual address of the next section, the XCOFFObjectWriter.cpp will hit a assert.

2.as discussed in the patch https://reviews.llvm.org/D66969,
since implemented the function description. We can output the raw object data for function.
we need to create a test for raw text section content and test section header for xcoff object file.

Reviewer: daltenty,hubert.reinterpretcast,jasonliu

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

Pickup the default crt and libs when the target is musl.
Resubmitting after updating the testcase.

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

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

Summary:
This revision fixes a -Wzero-length-array compile error that
caused e4595969 which reverted
78f9e5d0.
Also fixes a struct vs class mismatch that broke compilation with
-Werror for Windows that caused
57397eba.

This revision adds padding for 1-D Vector in the common case of x86
execution with a stadard data layout. This supports properly interfacing
codegen with arrays of e.g. `vector<9xf32>`.

Such vectors are already assumed padded to the next power of 2 by LLVM
codegen with the default x86 data layout:
```
define void @test_vector_add_1d_2_3(<3 x float>* nocapture readnone %0,
<3 x float>* nocapture readonly %1, i64 %2, i64 %3, i64 %4, <3 x float>*
nocapture readnone %5, <3 x float>* nocapture readonly %6, i64 %7, i64
%8, i64 %9, <3 x float>* nocapture readnone %10, <3 x float>* nocapture
%11, i64 %12, i64 %13, i64 %14) local_unnamed_addr {
  %16 = getelementptr <3 x float>, <3 x float>* %6, i64 1
  %17 = load <3 x float>, <3 x float>* %16, align 16
  %18 = getelementptr <3 x float>, <3 x float>* %1, i64 1
  %19 = load <3 x float>, <3 x float>* %18, align 16
  %20 = fadd <3 x float> %17, %19
  %21 = getelementptr <3 x float>, <3 x float>* %11, i64 1
```

The pointer addressing a `vector<3xf32>` is assumed aligned `@16`.
Similarly, the pointer addressing a `vector<65xf32>` is assumed aligned
`@512`.

This revision allows using objects such as `vector<3xf32>` properly with
the standard x86 data layout used in the JitRunner. Integration testing
is done out of tree, at the moment such testing fails without this
change.

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

This revision adds a static `mlir_c_runner_utils_static` library
for the sole purpose of being linked into `mlir_runner_utils` on
Windows.

It was previously reported that:
```

`add_llvm_library(mlir_c_runner_utils SHARED CRunnerUtils.cpp)`

produces *only* a dll on windows, the linking of mlir_runner_utils fails
because target_link_libraries is looking for a .lib file as opposed to a
.dll file. I think this may be a case where either we need to use
LINK_LIBS or explicitly build a static lib as well, but I haven't tried
either yet.
```

This reverts commit 3a063d68.

Broke the build with modules enabled:
http://green.lab.llvm.org/green/job/lldb-cmake/10655/console .

The incoming back chain slot was implicitly allocated whenever a GPR was
saved in SystemZFrameLowering::getRegSpillOffset(), but in cases where no
GPRs were saved/restored this did not take effect.

Review: Ulrich Weigand

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

Response files where not being correctly read on Windows, this change
fixes the issue and adds some tests.

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

Summary:
This patch introduces the `clang_analyzer_isTainted` expression inspection
check for checking taint.

Using this we could query the analyzer whether the expression used as the
argument is tainted or not. This would be useful in tests, where we don't want
to issue warning for all tainted expressions in a given file
(like the `debug.TaintTest` would do) but only for certain expressions.

Example usage:

```lang=c++
int read_integer() {
  int n;
  clang_analyzer_isTainted(n);     // expected-warning{{NO}}
  scanf("%d", &n);
  clang_analyzer_isTainted(n);     // expected-warning{{YES}}
  clang_analyzer_isTainted(n + 2); // expected-warning{{YES}}
  clang_analyzer_isTainted(n > 0); // expected-warning{{YES}}
  int next_tainted_value = n; // no-warning
  return n;
}
```

Reviewers: NoQ, Szelethus, baloghadamsoftware, xazax.hun, boga95

Reviewed By: Szelethus

Subscribers: martong, rnkovacs, whisperity, xazax.hun,
baloghadamsoftware, szep...

Forming subtract with overflow is beneficial on SystemZ, just like additions.

Review: Ulrich Weigand

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

Summary:

Reviewers: sammccall

Subscribers: mgorny, ilya-biryukov, MaskRay, jkorous, arphaman, usaxena95, cfe-commits

Tags: #clang

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

Reviewers: hokein, sammccall

Subscribers: ilya-biryukov, MaskRay, jkorous, arphaman, usaxena95, cfe-commits

Tags: #clang

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

Reviewers: sammccall

Subscribers: cfe-commits

Tags: #clang

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

Summary: This patch adds an analysis pass to collect loop nests and
summarize properties of the nest (e.g the nest depth, whether the nest
is perfect, what's the innermost loop, etc...).

The motivation for this patch was discussed at the latest meeting of the
LLVM loop group (https://ibm.box.com/v/llvm-loop-nest-analysis) where we
discussed
the unimodular loop transformation framework ( “A Loop Transformation
Theory and an Algorithm to Maximize Parallelism”, Michael E. Wolf and
Monica S. Lam, IEEE TPDS, October 1991). The unimodular framework
provides a convenient way to unify legality checking and code generation
for several loop nest transformations (e.g. loop reversal, loop
interchange, loop skewing) and their compositions. Given that the
unimodular framework is applicable to perfect loop nests this is one
property of interest we expose in this analysis. Several other utility
functions are also provided. In the future other properties of interest
can be added in a centralized place.
Authored By: etiotto
Reviewer: Meinersbur, bmahjour, kbarton, Whitney, dmgreen, fhahn,
reames, hfinkel, jdoerfert, ppc-slack
Reviewed By: Meinersbur
Subscribers: bryanpkc, ppc-slack, mgorny, hiraditya, llvm-commits
Tag: LLVM
Differential Revision: https://reviews.llvm.org/D68789

Summary: This patch adds a new way to query operand bundles of an llvm.assume that is much better suited to some users like the Attributor that need to do many queries on the operand bundles of llvm.assume. Some modifications of the IR like replaceAllUsesWith can cause information in the map to be outdated, so this API is more suited to analysis passes and passes that don't make modification that could invalidate the map.

Reviewers: jdoerfert, sstefan1, uenoku

Reviewed By: jdoerfert

Subscribers: hiraditya, llvm-commits

Tags: #llvm

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

This patch adds a getPlan accessor to VPBlockBase, which finds the entry
block of the plan containing the block and returns the plan set for this
block.

VPBlockBase contains a VPlan pointer, but it should only be set for
the entry block of a plan. This allows moving blocks without updating
the pointer for each moved block and in the future we might introduce a
parent relationship between plans and blocks, similar to the one in LLVM IR.

Reviewers: rengolin, hsaito, fhahn, Ayal, dorit, gilr

Reviewed By: gilr

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

Instead of a ExecutionContext*. All it needs is the target so it can
read the memory.

This removes some defensive checks from the function. I've added
equivalent checks to the callers in cases where a non-null target
pointer was not guaranteed to be available.