As discussed in the mailing list [1-4], we need a separation of support
tiers when requiring support from the whole community versus a
sub-community. Essentially, if a sub-community is active enough and
takes maintenance into their own internal costs without affecting other
parts of the community's maintenance costs, then code that is not
immediately relevant to all parts (ie. not released, actively tested,
etc) can still find its way into the LLVM main repository without major
pain points.

The main benefit is to reduce the maintenance cost that those
sub-communities have outside of LLVM (for example, in duplicating common
code, applying the same patches on top of multiple user repositories or
downstream projects).

This document outlines the components and responsibilities of the
sub-communities with regards to maintenance costs and how they affect
the rest of the community.

It also adds an addendum on removal policies, which expand the existing
"new target removal" policy into something more generic, to encompass
any piece of code, scripts or documents in the repository.

[1] http://lists.llvm.org/pipermail/llvm-dev/2020-October/146249.html
[2] http://lists.llvm.org/pipermail/llvm-dev/2020-November/146335.html
[3] http://lists.llvm.org/pipermail/llvm-dev/2020-October/146138.html
[4] http://lists.llvm.org/pipermail/llvm-dev/2020-November/146298.html

The config providers that look for configuration files currently take a pointer to a FileSystem in the constructor.
For some reason this isn't actually used when trying to read those configuration files, Essentially it just follows the behaviour of the real filesystem.
Using clang-tidy standalone this doesn't cause any issue.
But if its used as a library and the user wishes to use say an `InMemoryFileSystem` it will try to read the files from the disc instead.

Reviewed By: aaron.ballman

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

Convert analyzeContextInfo to a work list using the same approach I used
to remove the recursion from lookForDIEsToKeep. This fixes the crash
reported in https://llvm.org/PR48029.

Tested using the reproducer attached to PR48029 as well as by comparing
the clang MD5 hashes before and after the change (with and without
gmodules).

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

Use skipUnlessDarwin decorator for tests that are specific to Darwin,
instead of skipIf... for all other platforms.  This should make it clear
that these tests are not supposed to work elsewhere.  It will also make
these tests stop repeatedly popping up while I look for tests that could
be fixed on the platform in question.

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

This reverts commit 33039805.

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

The distinction between StructOffset and OtherOffset has been
originally introduced by 82069c44,
which applied different reasoning to both offset kinds. However,
this distinction was not actually correct, and has been fixed by
c84e77ae. Since then, we only ever
consider the sum StructOffset + OtherOffset, so we may as well
store it in that form directly.

* Introduced issue in debug builds.

This reverts commit b5fcd061.

Instead of performing the multiplication in double the bit width
and using active bits to determine overflow, use the existing
smul_ov() APInt method to detect overflow.

The smul_ov() implementation is not particularly efficient, but
it's still better than doing this a wide, usually 128-bit, type.

Reviewed By: mehdi_amini

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

* Moved various loose functions to either the mlir::tosa namespace or made static
* Fixed an unused variable warning in TosaMakeBroadcastable.cpp.

This is the TOSA MLIR Dialect described in the following MLIR RFC: https://llvm.discourse.group/t/rfc-tosa-dialect-in-mlir/1971/24

Reviewed By: stellaraccident

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

Reviewers: rnk, dblaikie

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

Add basic statistics on the number of pointers that have been
determined to maybe capture / not capture.

If there are too many uses, we should directly return -- there's
no point in inspecting the remaining uses in the worklist, as we
have to conservatively assume a capture anyway. This also means
that tooManyUses() gets called exactly once, rather than
potentially many times.

This restores the behavior prior to e9832dfd,
where this was accidentally changed while moving the AddUses logic
into a closure, thus making the return a return from the closure
rather than the whole function.

If the same value is used multiple times in the same instruction,
CaptureTracking may end up reporting the wrong use as being captured,
and/or report the same use as being captured multiple times.

Make sure that all checks take the use operand number into account,
rather than performing unreliable comparisons against the used value.

I'm not sure whether this can cause any problems in practice, but
at least some capture trackers (ArgUsesTracker, AACaptureUseTracker)
do care about which call argument is captured.

Since SPIR-V module has an optional name, this patch
makes a change to pass it to `ModuleOp` during conversion.

Reviewed By: ftynse

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

We check shouldExplore() before adding uses to the worklist, so
uses that should not be explored will not reach captured() in the
first place.

Reduce the size of the WorklistItem struct by using a struct.

The patch simplifies BranchProbabilityInfo::getEdgeProbability by
handling two cases separately, depending on whether we have edge
probabilities.

- If we have edge probabilities, then add up probabilities for
  successors being equal to Dst.

- Otherwise, return the number of ocurrences divided by the total
  number of successors.

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

after D89158

This reverts commit 0b17c6e4. This patch
causes a compile-time error in SCEV.

This reverts commit b1878b46. This does
fix the test but it means that ac73b73c is not implemented
correctly. Reverting for now, and will be reverting the commit that
causes this to fail.

By turning the loop into an infinite one, the loop can't be deleted
anymore so the test will continue to pass.

to be consistent with other emit*

The commit 0b17c6e4 occasionally causes this test to
fail, this fixes it.

Eliminate the need to go through the DIE index by passing the DIE to
CompileUnit::getInfo directly.

Before:

  unsigned Idx = Unit->getOrigUnit().getDIEIndex(Die);
  CompileUnit::DIEInfo &Info = Unit->getInfo(Idx);

After:

  CompileUnit::DIEInfo &Info = Unit->getInfo(Die);

From C11 and C++11 onwards, a forward-progress requirement has been
introduced for both languages. In the case of C, loops with non-constant
conditionals that do not have any observable side-effects (as defined by
6.8.5p6) can be assumed by the implementation to terminate, and in the
case of C++, this assumption extends to all functions. The clang
frontend will emit the `mustprogress` function attribute for C++
functions (D86233, D85393, D86841) and emit the loop metadata
`llvm.loop.mustprogress` for every loop in C11 or later that has a
non-constant conditional.

This patch modifies LoopDeletion so that only loops with
the `llvm.loop.mustprogress` metadata or loops contained in functions
that are required to make progress (`mustprogress` or `willreturn`) are
checked for observable side-effects. If these loops do not have an
observable side-effect, then we delete them.

Loops without observable side-effects that do not satisfy the above
conditions will not be deleted.

Reviewed By: jdoerfert

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

In order not to modify the `tgt_target_data_update` information but still be
able to pass the extra information for non-contiguous map item (offset,
count, and stride for each dimension), this patch overload `arg` when
the maptype is set as `OMP_MAP_DESCRIPTOR`. The origin `arg` is for
passing the pointer information, however, the overloaded `arg` is an
array of descriptor_dim:

struct descriptor_dim {
  int64_t offset;
  int64_t count;
  int64_t stride
};

and the array size is the same as dimension size. In addition, since we
have count and stride information in descriptor_dim, we can replace/overload the
`arg_size` parameter by using dimension size.

For supporting `stride` in array section, we use a dummy dimension in
descriptor to store the unit size. The formula for counting the stride
in dimension D_n: `unit size * (D_0 * D_1 ... * D_n-1) * D_n.stride`.

Demonstrate how it works:
```
double arr[3][4][5];

D0: { offset = 0, count = 1, stride = 8 }                                // offset, count, dimension size always be 0, 1, 1 for this extra dimension, stride is the unit size
D1: { offset = 0, count = 2, stride = 8 * 1 * 2 = 16 }                   // stride = unit size * (product of dimension size of D0) * D1.stride = 4 * 1 * 2 = 8
D2: { offset = 2, count = 2, stride = 8 * (1 * 5) * 1 = 40  }            // stride = unit size * (product of dimension size of D0, D1) * D2.stride = 4 * 5 * 1 = 20
D3: { offset = 0, count = 2, stride = 8 * (1 * 5 * 4) * 2 = 320 }        // stride = unit size * (product of dimension size of D0, D1, D2) * D3.stride = 4 * 25 * 2 = 200

// X here means we need to offload this data, therefore, runtime will transfer
// data from offset 80, 96, 120, 136, 400, 416, 440, 456
// Runtime patch: https://reviews.llvm.org/D82245
// OOOOO OOOOO OOOOO
// OOOOO OOOOO OOOOO
// XOXOO OOOOO XOXOO
// XOXOO OOOOO XOXOO
```

Reviewed By: ABataev

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

This patch is the runtime support for https://reviews.llvm.org/D84192.

In order not to modify the tgt_target_data_update information but still be
able to pass the extra information for non-contiguous map item (offset,
count, and stride for each dimension), this patch overload arg when
the maptype is set as OMP_TGT_MAPTYPE_DESCRIPTOR. The origin arg is for
passing the pointer information, however, the overloaded arg is an
array of descriptor_dim:

```
struct descriptor_dim {
  int64_t offset;
  int64_t count;
  int64_t stride
};
```

and the array size is the dimension size. In addition, since we
have count and stride information in descriptor_dim, we can replace/overload the
arg_size parameter by using dimension size.

Reviewed By: grokos

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

The tests are intended to exercise the public C API and will link to a
specific shared library exposing only the C API, this library itself may
link to libMLIR.so.
If we link some LLVM library statically in the test themselves, we end
up with duplicated cl::opt registrations in LLVM. A possible setup if
these libraries were needed could be to link libMLIR.so directly when
available and link statically when it isn't available (in which case the
libary exposing the C API would be statically link and isolated from the
cl::opt registry, hopefully).

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