[mlir][Linalg][Transform] Avoid FunctionalStyleTransformOpTrait where unnecesseary to improve usability

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

applyLoopGuards doesn't always preserve information when there are multiple assumes.

This patch tries to deal with multiple assumes regarding a SCEV's divisibility and min/max values, and rewrite it into a SCEV that still preserves all of the information.
For example, let the trip count of the loop be TC. Consider the 3 following assumes:

1. __builtin_assume(TC % 8 == 0);
2. __builtin_assume(TC > 0);
3. __builtin_assume(TC < 100);

Before this patch, depending on the assume processing order applyLoopGuards could create the following SCEV:
max(min((8 * (TC / 8)) , 99), 1)

Looking at this SCEV, it doesn't preserve the divisibility by 8 information.

After this patch, depending on the assume processing order applyLoopGuards could create the following SCEV:
max(min((8 * (TC / 8)) , 96), 8)

By aligning up 1 to 8, and aligning down 99 to 96, the new SCEV still preserves all of the original assumes.

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

The token annotator doesn't annotate the template opener and closer
as such if they enclose an overloaded operator. This causes the
space between the operator and the closer to be removed, resulting
in invalid C++ code.

Fixes #58602.

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

Add a clang part of OpenHarmony target

Related LLVM part: D138202

~~~

Huawei RRI, OS Lab

Reviewed By: DavidSpickett

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

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

Update lowering of allocate statement to use the new
functions defined in D146290.

Depends on D146290

Reviewed By: PeteSteinfeld

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

`AllocatableInitIntrinsic`, `AllocatableInitCharacter` and
`AllocatableInitDerived` are meant to be used to initialize a
descriptor when it is instantiated and not to be used multiple
times in a scope.
Add `AllocatableInitDerivedForAllocate`, `AllocatableInitCharacterForAllocate`
and `AllocatableInitDerivedForAllocate` to be used for the allocation
in allocate statement.
These new functions are meant to be used on an initialized descriptor
and will return directly if the descriptor is allocated so the
error handling is done by the call to `AllocatableAllocate`.

Reviewed By: PeteSteinfeld

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

This reverts commit c1888a37
because of massive buildbolt failures.

This revisions refactors the implementation of mapping to threads to additionally allow warps and linear ids to be specified.

`warp_dims` is currently specified along with `block_dims` as a transform attribute.

Linear ids on th other hand use the flattened block_dims to predicate on the first (linearized) k threads.
An additional GPULinearIdMappingAttr is added to the GPU dialect to allow specifying loops mapped to this new scheme.

Various implementation and transform op semantics cleanups are also applied.

Reviewed By: ThomasRaoux

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

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

This reverts commit 22c3ba4b.

Breaks buildbot https://lab.llvm.org/buildbot/#/builders/197/builds/4272

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

This reverts commit b05dc1b8.

Makes clang-format crash on `struct Foo { operator enum foo{} };`

1. Align ManualMapSet with X86MemoryFoldTableEntry instead of using UnfoldStrategy
2. ManualMapSet able to update the existing record in auto-generated MemFold table

Reviewed By: skan

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

There is a piece of logic in GuardWidening which is very limited, and it happens
to ignore implicit control flow, therefore it "works fine" with guards expressed as
intrinsic calls. However, when the guards are represented as branches, its limitations
create a lot of trouble.

The intent here is to make sure that we do not widen code across complex CFG,
so that it can end up being in hotter code than it used to be. The old logic was limited
to unique immediate successor and that's it.

This patch changes the logic there to work the following way: when we need to check
if we can widen from `DominatedBlock` into `DominatingBlock`, we first try to find the
lowest (by CFG) transitive successor  of `DominatingBlock` which is guaranteed to not
be significantly colder than the `DominatingBlock`. It means that every time we move
to either:

- Unique successor of the current block, if it only has one successor;
- The only taken successor, if the current block ends with `br(const)`;
- If one of successors ends with deopt, another one is taken;

If the lowest block we can find this way is the `DominatedBlock`, then it is safe to assume
that this widening won't move the code into a hotter location.

I did not touch the existing check with PDT. It looks fishy to me (post-dominance doesn't
really guarantee anything about hotness), but let's keep it as is and maybe fix later.

With this patch, Guard Widening can widen explicitly expressed branches across more than one
dominating guard if it's profitable.

Differential Revision: https://reviews.llvm.org/D146276
Reviewed By: skatkov

Despite the fact that it is legal, it is not profitable. It may prevent
Loop Guard Widening to happen. Because of bug described at
https://github.com/llvm/llvm-project/issues/60234, now the guard widening is
only possible when condtion we want to add is available at the point of the
widenable_condition() of dominating guard. It means that, if all such calls are
hoisted out of loop, and the loop conditions depend on loop-variants, we cannot
widen. Hoisting is otherwise not helpful, because it does not introduce any
optimization opportunities.

Differential Revision: https://reviews.llvm.org/D146274
Reviewed By: apilipenko

Reviewed By: arsenm

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

Close https://github.com/llvm/llvm-project/issues/38554
Close https://github.com/llvm/llvm-project/issues/58532

It looks like we can workaround the '#pragma once' problem automatically
after we force the lazily loading for named modules. Add a test to show
this.

Update JITDylib's symbol table entry struct to use the newer ExecutorAddr type.

Branch operands are different from regular instructions. They can have a mix of boolean values and branch instructions. This makes sure that branches are treated as more of a special case and makes sure that the successor blocks are always in the same order, and that they do not include the conditional argument.

Reviewer: paquette
Differential Revision: https://reviews.llvm.org/D139337

Reviewed By: asbirlea

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

This reverts commit bdf5f9c3, which was a work
in progress for https://reviews.llvm.org/D144276 and accidentally committed
early.

This reverts commit b6a0be8c.

This reverts commit f890f010.

Simplifies the process of building an LLJIT instance that supports the native
platform features (initializers, TLV, etc.).

SetUpExecutorNativePlatform can be passed to LLJITBuilder::setPlatformSetUp
method. It takes a reference to the ORC runtime (as a path or an in-memory
archive) and automatically sets the platform for LLJIT's ExecutionSession based
on the executor process's triple.

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

- `intrinsic-pointer-to-any.td`
- `intrinsic-varargs.td`

They used their own mock.

I have introduced `TEST_INTRINSICS_SUPPRESS_DEFS` in `Intrinsics.td`.
Tests of intrinsics may use it.

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

Back in D128714, we should have replaced the old rule about colons when
we added the new one.  Because we didn't, all colons got mistaken as
case colons as long as the line began with `case` or `default`.  Now we
remove the rule that we forgot to remove.

Reviewed By: MyDeveloperDay, rymiel

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

Update the code to collect the initializer when collecting the types for
a global, as suggested by @nikic in D144476.

This replaces code which bailed out if *any* part doesn't have an
initializer with a continue to just skip parts which don't have an
initializer.

Depends on D145489.

Reviewed By: nikic

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

This patch precommits tests for:

https://github.com/llvm/llvm-project/issues/60802

Internal linkages fails when building libc++ with modules. Using
internal linkage is headers seems questionable to change the linkage.

Reviewed By: #libc, philnik

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

This can help flag accidentally passing in negative values into the  `string_view` constructor. This aligns with a similar check in `absl::string_view`.

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

Reviewed By: #libc, Mordante

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

This allows the compiler to inline the constructors.

Reviewed By: ldionne, #libc

Spies: mikhail.ramalho, libcxx-commits

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

This paper has been applied to the working draft and is believed to be
a DR against C++20, so that the patch here makes the change unconditionally.

for:
```
export module A;

const int mod_cst = 10;
```
Before the change, mod_cst would have internal linkage; after the change it
has module linkage.

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

Fix a few typos and remove TODOs

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

As explained in the release note, libc++ used to provide various
global variables as an extension in C++03 mode. Unfortunately, that
made our definition non-conforming in all standard modes. This was
never a big problem until recently, since we are trying to support
C++20 Modules in libc++, and that requires cleaning up the definition
of these variables.

This change is the first in a series of changes to achieve our end goal.
This patch removes the ability for users to rely on the (incorrect)
definition of those global variables inside the shared library. The
plan is to then remove those definitions from the shared library
(which is an ABI break but I don't think it will have impact), and
finally to make our definition of those variables conforming in all
standard modes.

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