Breaks some bots, details in https://reviews.llvm.org/D91620

This reverts commit 93b1256e.

Breaks https://lab.llvm.org/buildbot/#/builders/168/builds/9288

This reverts commit 83839700.

This extension to the sparse tensor type system in MLIR
opens up a whole new set of sparse storage schemes, such as
block sparse storage (e.g. BCSR) and ELL (aka jagged diagonals).

This revision merely introduces the type extension and
initial documentation. The actual interpretation of the type
(reading in tensors, lowering to code, etc.) will follow.

Reviewed By: Peiming

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

Partially implements:
- P1361 Integration of chrono with text formatting

Reviewed By: ldionne, #libc

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

isBeforeInTranslationUnit compares SourceLocations across FileIDs by
mapping them onto a common ancestor file, following include/expansion edges.

It is possible to get a tie in the common ancestor, because multiple
"chunks" of a macro arg will expand to the same macro param token in the body:
  #define ID(X) X
  #define TWO 2
  ID(1 TWO)
Here two FileIDs both expand into `X` in ID's expansion:
 - one containing `1` and spelled on line 3
 - one containing `2` and spelled by the macro expansion of TWO
isBeforeInTranslationUnit breaks this tie by comparing the two FileIDs:
the one "on the left" is always created first and is numerically smaller.
This seems correct so far.

Prior to this patch it also takes a shortcut (unclear if intentionally).
Instead of comparing the two FileIDs that directly expand to the same location,
it compares the original FileIDs being compared. These may not be the
same if there are multiple macro expansions in between.
This *almost* always yields the right answer, because macro expansion
yields "trees" of FileIDs allocated in a contiguous range: when comparing tree A
to tree B, it doesn't matter what representative you pick.

However, the splitting of >> tokens is modeled as macro expansion (as if
the first '>' was a macro that expands to a '>' spelled a scratch buffer).
This splitting occurs retroactively when parsing, so the FileID allocated is
larger than expected if it were a real macro expansion performed during lexing.
As a result, macro tree A can be on the left of tree B, and yet contain
a token-split FileID whose numeric value is *greator* than those in B.
In this case the tiebreak gives the wrong answer.

Concretely:
  #define ID(X) X
  template <typename> class S{};
  ID(
    ID(S<S<int>> x);
    int y;
  )

  Given Greater = (typeloc of S<int>).getEndLoc();
        Y       = (decl of y).getLocation();
  isBeforeInTranslationUnit(Greater, Y) should return true, but returns false.

Here the common FileID of (Greater, Y) is the body of the outer ID
expansion, and they both expand to X within it.
With the current tiebreak rules, we compare the FileID of Greater (a split)
to the FileID of Y (a macro arg expansion into X of the outer ID).
The former is larger because the token split occurred relatively late.

This patch fixes the issue by removing the shortcut. It tracks the immediate
FileIDs used to reach the common file, and uses these IDs to break ties.
In the example, we now compare the macro arg expansion of the inner ID()
to the macro arg expansion of Y, and find that it is smaller.

This requires some changes to the InBeforeInTUCacheEntry (sic).
We store a little more data so it's probably slightly slower.
It was difficult to resist more invasive changes:
 - performance: the sizing is very suspicious, and once the cache "fills up"
   we're thrashing a single entry
 - API: the class seems to be needlessly complicated
However I tried to avoid mixing these with subtle behavior changes, and
will send a followup instead.

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

Allow register binding attribute on variables.

Report warning when register binding attribute applies to local variable or static variable.
It will be ignored in this case.

Type check for register binding is tracked with https://github.com/llvm/llvm-project/issues/57886.

Reviewed By: aaron.ballman

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

Sometimes when a function is inlined into a different CU, `llvm-dwarfdump --verify` would find an inlined subroutine with an invalid abstract origin. This is because `DwarfUnit::addDIEEntry()` will incorrectly assume the inlined subroutine and the abstract origin are from the same CU if it can't find the CU for the inlined subroutine.

In the added test, the inlined subroutine for `bar()` is created before the CU for `B.swift` is created, so it tries to point to `goo()` in the wrong CU. Interestingly, if we swap the order of the two functions then we don't see a crash since the module for `goo()` is created first.

The fix is to give a parent DIE to `ScopeDIE` before calling `addDIEEntry()` so that its CU can be found. Luckily, `constructInlinedScopeDIE()` is only called once so we can pass it the DIE of the scope's parent and give it a child just after it's created.

`constructInlinedScopeDIE()` should always return a DIE, so assert that it is not null.

Reviewed By: aprantl

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

The test Dialect/Affine/ops.mlir was failing when building with
Visual Studio 2022 version 17.3.5. This was caused by a bad MSVC codegen, when
capturing a `constexpr` in a lambda. The bug was reported to Microsoft, see
differential for more information.

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

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

As briefly discussed on https://reviews.llvm.org/rG1134d3a03facccd75efc5385ba46918bef94fcb6, fix the unintended copy while iterating on Reservations and add a mutex guard, to be symmetric with other usages of Reservations.

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

A few cases were not handled correctly. Notably:
  #define ID(X) X
  #define HIDE a ID(b)
  HIDE
spelledForExpanded() would claim HIDE is an equivalent range of the 'b' it
contains, despite the fact that HIDE also covers 'a'.

While trying to fix this bug, I found findCommonRangeForMacroArgs hard
to understand (both the implementation and how it's used in spelledForExpanded).
It relies on details of the SourceLocation graph that are IMO fairly obscure.
So I've added/revised quite a lot of comments and made some naming tweaks.

Fixes https://github.com/clangd/clangd/issues/1289

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

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

The callers of getConstraint only require a list of new variables.
Update the naming and types to make this clearer.

For V_CMP_CLASS_F16_t16_e64 and V_CMPX_CLASS_F16_t16_e64,
https://reviews.llvm.org/D133723 changed the value type of src1 from i32 to i16.
These src1 operands are 16 bits, therefore need to be encoded as true16
operands. So the _e32 type was correctly set to VGPR_32_Lo128.
In _e64 form the operand class went from
VSrc_b32 to VSrc_b16. For some reason, we cannot encode inline literals for
VSrc_b16, see 5f5f566b. In this phase of
the true16 implementation, VSrc_b16 and VSrc_b32 are still similar,
except from that quirk of inlines. So set the operand class to regain
that function.

Reviewed By: dp, arsenm

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

Run through opt -instnamer.

Partially implements:
- P1361 Integration of chrono with text formatting

Reviewed By: ldionne, #libc

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

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

Using https://gist.github.com/nikic/98357b71fd67756b0f064c9517b62a34.

The opaque pointer migration resolves the TODO on test_fence3: The
transform now works as expected by dint of the bitcast no longer
existing.

Such GEPs don't exist with opaque pointers, give it an actual
offset.

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

These were all changed in 32b1b06b (as
discussed in D133967) but some intrinsics introduced since have
re-introduced `undef` as the masked-off value.

Reviewed By: reames, eopXD

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

More uses of getSEWLMULRatio will be added in D130895.

Reviewed By: craig.topper, frasercrmck

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

Polymorphic and unlimited polymorphic entities should be handled by runtime. This patch
update the condition in `genDeallocate` to force polymorphic and unlimited polymorphic entities
to be deallocated through a runtime call and not inlined.

Depends on D135143

Reviewed By: jeanPerier, PeteSteinfeld

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

Using https://gist.github.com/nikic/98357b71fd67756b0f064c9517b62a34.

This prepares for printName() to print `(anonymous struct)` etc in D134813.

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

It shows up on profiles, albeit only at 0.1% or so.

The atomic operations behave similar to a store except that we don't
know the new value and we read the result first.

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

Setting up a lazy-save mechanism around calls is done during SelectionDAG
because calls to intrinsics may be expanded into an actual function call
(e.g. calls to @llvm.cos()), and maintaining an allowed-list in the SMEABI
pass is not feasible.

The approach for conditionally restoring the lazy-save based on the runtime
value of TPIDR2_EL0 is similar to how we handle conditional smstart/smstop.
We create a pseudo-node which gets expanded into a conditional branch and
expands to a call to __arm_tpidr2_restore(%tpidr2_object_ptr).

The lazy-save buffer and TPIDR2 block are only allocated once at the start
of the function. For each call, the TPIDR2 block is initialised, and at
the end of the call, a pseudo node (RestoreZA) is planted.

Patch by Sander de Smalen.

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

If a call base use will not capture a pointer we can approximate the
effects. This is important especially for readnone/only uses. Even
may-write uses are not too bad with reachability in place. Capturing
is the problem as we loose track of update sides.

update_tests_checks.py generates the same identifier for lowercase
and uppercase variable names. Make sure they have a distinct name.

LookupSpecialMember might fail, so changes the cast to cast_or_null.
Inside Sema, skip a particular base, similar to other cases, rather than
asserting on dtor showing up.

Other option would be to mark classes with invalid destructors as invalid, but
that seems like a lot more invasive and we do lose lots of diagnostics that
currently work on classes with broken members.

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

If we have a constant aggregate, e.g., as an initializer, we usually
failed to extract the proper value/type from it. This patch provides the
size and offset information necessary to extract the right part of the
constant.

Converted using the script at
https://gist.github.com/nikic/98357b71fd67756b0f064c9517b62a34.

This was already handled correctly below, but not checked for the
original store pointer operand. Encountered when converting tests
to opaque pointers, where the intermediate bitcast goes away.

Currently the following case fails:
```
template<typename Ty>
Ty foo(Ty *addr, Ty val) {
  Ty v;
#pragma omp atomic compare capture
  {
    v = *addr;
    if (*addr > val)
      *addr = val;
  }
  return v;
}
```

The compiler complains `addr` is not a lvalue. That's because when an expression
is instantiation dependent, we cannot tell if it is lvalue or not.

Reviewed By: ABataev

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