The implementation had a couple of problems, including checking
"isProperAncestor" in an inefficient way.  It also recursed into
other "isolated from above" ops.  In the case of CIRCT, we get
three levels of isolated ops:

  mlir::ModuleOp
    firrtl::CircuitOp
       firrtl::FModuleOp

The verification for module would recurse into the circuits and
fmodules checking them.  The verifier hook for circuit would
recurse into all the modules reverifying them, fmoduleop would
then reverify them.  The same happens for mlir::ModuleOp and Func.

While here, fix an old design problem: IsolatedFromAbove checking
was implemented by a method on the Region class, which isn't
actually general and isn't used by anything else.  Move it over
to be a trait impl verifier method like the others and specialize
it for its task.

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

This doesn't actually have any effect: we only call this code with
SequentiallyConsistent orderings.  But delete it anyway for consistency
with other recent changes.

When fulling unrolling with a non-latch exit, the latch block is
folded to unreachable. Replace this folding with the existing
changeToUnreachable() helper, rather than performing it manually.

This also moves the fold to happen after the manual DT update
for exit blocks. I believe this is correct in that the conversion
of an unconditional backedge into unreachable should not affect
the DT at all.

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

This is cleaner than slicing the MxList to remove elements from
the beginning or end since that requires hardcoding the size.

I don't expect the size of the list to change, but we shouldn't
repeat it in multiple places.

This is to show that we currently only convert the terminator to
unreachable, but don't clean up instructions before it (unless
trivial DCE removes them).

Also clean up excessive whitespace in this test.

This does some non-functional cleanup of exit folding during
unrolling. The two main changes are:

 * First rewrite latch->header edges, which is unrelated to exit
   folding.
 * Combine folding for latch and non-latch exits. After the
   previous change, the only difference in their logic is that
   for non-latch exits we currently only fold "known non-exit"
   cases, but not "known exit" cases.

I think this helps a lot to clarify this code and prepare it for
future changes.

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

We now have llvm-otool :)

Forgotten in commits fce8c10b, 9363aa90, 8d93d7ff.

If a cmpxchg specifies acquire or seq_cst on failure, make sure we
generate code consistent with that ordering even if the success ordering
is not acquire/seq_cst.

At one point, it was ambiguous whether this sort of construct was valid,
but the C++ standad and LLVM now accept arbitrary combinations of
success/failure orderings.

This doesn't address the corresponding issue in AtomicExpand. (This was
reported as https://bugs.llvm.org/show_bug.cgi?id=33332 .)

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

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

This should have been done in D96385; thanks ldionne for the catch!
Also, make the back/front inserter behavior tests a little more thorough,
which incidentally caught a cut-and-paste-bug in `nasty_list`, so fix that.

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

octuple_from_str was always used with the MX field from an
LMULInfo. Might as well just precompute it and put it in the class.

This reverts commit dc672999.
Breaks check-clang everywhere, see https://reviews.llvm.org/D91630

Parameter positions seem like they should be unsigned.

While there, make function names lowercase per coding standards.

Reviewed By: frasercrmck

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

We need to make sure that the indices of all extracts we scalarize are
valid.

Revert "Return "[LoopDeletion] Break backedge if we can prove that the loop is exited on 1st iteration" (try 2)"

This reverts commit be1a2320.

Revert "[NFCI][LoopDeletion] Only query SCEV about loop successor if another successor is also in loop"

This reverts commit b0b2bf3b.

This reverts commit 59d938e6.

This reverts commit c4675856.

This reverts commit 7d418dad.

This is split off from D102002, and I think it is clear that
the difference in behavior was not intended. Options were
added to SimplifyCFG over time, but different chunks of
the pass pipelines were not kept in sync.

Part of D102002

Tests for PR50511.

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

Revert "Fix "enumerator 'llvm::TargetStackID::WasmLocal' in switch of enum 'llvm::TargetStackID::Value' is not handled" MSVC warnings. NFCI."

Since ca5f07f8 already reverted
the cause for this warning, this commit now causes warnings about
a default label in a switch that covers the enum.

This reverts commit cf2eeb11.

This patch changes LoopFlattenPass from FunctionPass to LoopNestPass.

Utilize LoopNest and let function 'Flatten' generate information from it.

Reviewed By: Whitney

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

TypeFinder did not find types under DIArgList. This resulted in a case
of invalid IR after GlobalOpt removed a global that was the only
non-DIArgList use of a struct type.

  error: use of undefined type named 'struct.S'
    call void @llvm.dbg.value(
      metadata !DIArgList([1 x %struct.S]* undef, i64 %idxprom),
      metadata !24, metadata !DIExpression([...]))

Reviewed By: jmorse

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

Apparently ubsan errors are non-fatal by default. If you introduce UB
into LLVM and run the tests, if errors are not fatal, the test will
still produce the expected output and the tests will pass. In order to
make ubsan errors show up as test failures, they have to be made fatal.
Pass the -fno-sanitize-recover=all flag to make it so.

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

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

Before this patch, the maximum size of the GHASH table was 2^31 buckets. However we were storing the bucket index into a TypeIndex which has an input limit of (2^31)-4095 indices, see this link. Any value above that limit will improperly set the TypeIndex's high bit, which is interpreted as DecoratedItemIdMask. This used to cause bad indices on extraction when calling TypeIndex::toArrayIndex().

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