Flang was generating invalid IR when there was a GOTO to the body
of a DO loop. This happened because the value of step, computed at
the beginning of the loop, was being reused at the end of the loop,
that, for unstructured loops, is in another basic block. Because of
this, a GOTO could skip the beginning of the loop, that defined
step, and yet try to use it at the end of the loop, which is
invalid.

Instead of reusing the step value, it can be recomputed if it is a
constant, or stored and loaded to/from a temporary variable, for
non-constant step expressions.

Note that, while this change prevents the generation of invalid IR
on the presence of jumps to DO loop bodies, what happens if the
program reaches the end of a DO loop without ever passing through
its beginning is undefined behavior, as some control variables,
such as trip, will be uninitialized. It doesn't seem worth the
effort and overhead to ensure this legacy extension will behave
correctly in this case. This is consistent with at least gfortran,
that doesn't behave correctly if step is not equal to one.

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

This reverts commit 3fa50358.

m_sve_state was not initialised which (I'm guessing) meant that
it could potentially be a value that matched a real SVE state.
Then we'd be acting as if we're streaming mode, for example,
without ever having the data required to back that up.

By sheer luck this only turn up on x86, AArch64 and ARM were fine.
It is UB regardless.

That commit introduced a trivial test breakage due to a bad rebase,
which this commit fixes.

[mlir][linalg][transform] Rename {masked_vectorize => vectorize => vectorize_children_and...}. (#66575)

This PR renames the vectorization transform ops as follows:

* `structured.masked_vectorize` => `structured.vectorize`. This reflects
the fact that since [recently](https://reviews.llvm.org/D157774) the op
can also handle the unmasked case.
* `structured.vectorize` =>
`structured.vectorize_children_and_applies_patterns`. This reflects the
fact that the op does not just vectorize the given payload op but all
vectorizable children contained in it, and applies patterns before and
after for preparation and clean-up.

This rename was discussed first
[here](https://reviews.llvm.org/D157774).

The PR also adapts and cleans ups the tablegen description of the
`VectorizeChildrenAndApplyPatternsOp` (formerly `VectorizeOp`).

This option has been superseded by the fixpoint verification
functionality.

expandCodeFor() was directly calling expandCodeForImpl(). Drop the
Impl variant.

Similar to #65598, if we're using a vslideup to insert a fixed length
vector into another vector, then we can work out the minimum number of
registers it will need to slide up across given the minimum VLEN, and
shrink the type operated on to reduce LMUL accordingly.

This is somewhat dependent on #66211 , since it introduces a subregister
copy that triggers a crash with -early-live-intervals in one of the
tests.

Stacked upon #66211

This reverts commit 43812c8c.

Due to failures on x86_64: https://lab.llvm.org/buildbot/#/builders/68/builds/60416

Derived-type-spec (such as `type(t)`) typically cause the instantiation
of a class which is also used to define the offsets of its data
components and the size of the class.

Fortran derived types are always "completely" defined (i.e., no
incomplete / opaque derived types exist on which we can build a pointer
to them like in C/C++) so they can have their offsets always computed.

However, we must be careful not to instantiate a derived type while it
is being defined. This can happen due to cycles introduced by forward
references, such as the one below.

```lang=fortran
  type t1
    type(t2), pointer :: b ! (A)
  end type t1

  type :: t2 ! (B)
    type(t1), pointer :: a ! (C)
  end type t2 ! (D)
```

At `(A)`, flang determines that this is a forward declaration so no
instantiation happens.

At `(B)`, flang determines `t2` is not a forward declaration anymore,
because we are defining it.

At `(C)`, flang chooses to instantiate `t1`. Instantiation ...

This reverts commit fb8f5915 and
b8e9450a.

Due to test suite failures on AArch64:
https://lab.llvm.org/buildbot/#/builders/183/builds/16057

Old iterator is invalidated upon SmallVector elements additions. Stores
index instead of iterator to avoid this.

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

PR: https://github.com/llvm/llvm-project/pull/66954

This adds the ability to read streaming SVE registers,
ZA, SVCR and SVG from core files.

Streaming SVE is in a new note NT_ARM_SSVE but otherwise
has the same format as SVE. So I've done the same as I
did for live processes and reused the existing SVE state
with an extra state for the mode variable.

ZA is in a note NT_ARM_ZA and again the handling matches
live processes. Except that it gets setup only once. A
disabled ZA reads as 0s as usual.

SVCR and SVG are pseudo registers, generated from the notes.

An important detail is that the notes represent what
you would have got if you read from ptrace at the time of
the crash.

This means that for a corefile in non-streaming mode,
there is still an NT_ARM_SSVE note and we check the header
flags to tell if it is active. We cannot just say if you
have the note you're in streaming mode.

The kernel does not provide register values for the inactive
mode and even if it did, they would be undefined, so if we find
st...

Check isSafeToExpand() before expanding the exit count. Otherwise
we may incorrectly speculate a udiv.

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

The wide stream tests should be marked as `UNSUPPORTED: no-wide-characters`,
not XFAIL.

To get the bot back to green as we figure out how to handle piping data
into a test running behind a SSH executor.

In order to reduce noise for a MR.

Precommit test ahead of https://reviews.llvm.org/D159533 for ISD::FSHR /
AMDGPUISD::PERM combine

Noticed on D159533 and I've finally deal with the x86 regressions - MatchingStackOffset wasn't peeking through AssertZext nodes while trying to find CopyFromReg/Load sources, it was only removing them if they were part of a (trunc (assertzext x)) pattern.

Don't generate enums from the main VectorOps.td file as that
transitively includes enums from Arith.

---------

Co-authored-by: Nicolas Vasilache <ntv@google.com>

Support for SPIRV added, updated test SPV_INTEL_optnone.ll using the script.

Previously https://reviews.llvm.org/D157858

This reverts commit a7b78cac.

With updates to the tests.

TestWatchTaggedAddress.py: Updated the expected watchpoint types,
though I'm not sure there should be a differnt default for the two
ways of setting them, that needs to be confirmed.

TestStepOverWatchpoint.py: Skipped this everywhere because I think
what used to happen is you couldn't put 2 watchpoints on the same
address (after alignment). I guess that this is now allowed because
modify watchpoints aren't accounted for, but likely should be.
Needs investigating.

This has been deprecated in favor of CMake's CMAKE_MSVC_RUNTIME_LIBRARY
in c6bd8734 .
Current release branch still contains it in deprecated status so no
existing end-users will be affected.

This seems to cause Clang to crash, see comments on the code review. Reverting
until the problem can be investigated.

> Part 1 of 3. This includes the LLVM back-end processing and profile
> reading/writing components. compiler-rt changes are included.
>
> Differential Revision: https://reviews.llvm.org/D138846

This reverts commit a50486fd.

This transform has caused a few issues with operations that can naturally be
extended. This patch just adds a debug option for disabling the transform,
useful for testing cases where it might not be profitable.

One big issue with DirectXShaderCompiler was test coverage: DXIL and
SPIR-V backends had their own tests. When a bug was found in one, the
other wasn't always checked. This lead to unequal support of HLSL for
both backends. We'd like to avoid those issues here, hence the
test-sharing.

By default, all the tests in this folder are marked as requiring
DirectX. But as SPIR-V support grows, each test drop this requirement,
and check the SPIR-V behavior.

I would have preferred to mark new tests as XFAIL for SPIR-V by default,
so we could differentiate real unsupported tests (as SPIR-V has no
equivalent), from newly added tests. But the way LIT is built, I don't
think this is possible.

---------

Signed-off-by: Nathan Gauër <brioche@google.com>

Now that VPInstruction can manage fast math flags via
VPRecipeWithIRFlags, use them directly to model the fast-math flags of
the select created for the final reduction value instead of adding them
late.

Code Object V2 has been deprecated for more than a year now. We can
safely remove it from LLVM.

- [clang] Remove support for the `-mcode-object-version=2` option.
- [lld] Remove/refactor tests that were still using COV2
- [llvm] Update AMDGPUUsage.rst
- Code Object V2 docs are left for informational purposes because those
code objects may still be supported by the runtime/loaders for a while.
- [AMDGPU] Remove COV2 emission capabilities.
- [AMDGPU] Remove `MetadataStreamerYamlV2` which was only used by COV2
- [AMDGPU] Update all tests that were still using COV2 - They are either
deleted or ported directly to code object v4 (as v3 is also planned to
be removed soon).

Dependent interfaces have been added a while ago and these TODOs can be
addressed now.

The RISCV-V-Spec[1] describes which RVV instructions are allowed to overlap between source operands and destination operands. Currently, most of these instructions are constrained with early-clobber.

This patch labels these instructions with TargetOverlapConstraintType in pseudo to indicate that these instructions can overlap.

The value of TargetOverlapConstraintType is:

1 -> default
2 -> narrow case
3 -> widen case

This information is useful for future optimization passes.

[1] https://github.com/riscv/riscv-v-spec/blob/master/v-spec.adoc#52-vector-operands

Reviewed By: craig.topper

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

This reverts commit 933ad5c8.

This caused 1 test failure and an unexpected pass on AArch64 Linux:
https://lab.llvm.org/buildbot/#/builders/96/builds/45765

Wasn't reported because the bot was already red at the time.

https://cplusplus.github.io/LWG/issue3655

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


Co-authored-by: Louis Dionne <ldionne.2@gmail.com>