Reviewed By: aartbik

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

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

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

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

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

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

D150718 allows variadics during GPU compilation, but we also need to do it for
the host compilation as well, as it will see the same code.

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

LLVM_ENABLE_ZLIB is set to On by default and does not imply that ZLIB
was actually found, only being set to FORCE_ON would imply that it was
found before control reached compiler-rt/test/CMakeLists.txt. Instead,
use ZLIB_FOUND which guarantees that zlib is available.

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

This reverts commit 9ed3d85e.

It broke some bots:
https://lab.llvm.org/buildbot/#/builders/245/builds/8876

This patch utilizes the helper function implemented in D149699 and thus folds the following cases:

```
bitreverse(logic_op(x, bitreverse(y))) -> logic_op(bitreverse(x), y)
bitreverse(logic_op(bitreverse(x), y)) -> logic_op(x, bitreverse(y))
bitreverse(logic_op(bitreverse(x), bitreverse(y))) -> logic_op(x, y) in multiuse case
```

Reviewed By: goldstein.w.n, RKSimon

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

Fold the following case on IR InstCombine pass. This patch includes the new test cases for this optimization

```
bitreverse(logic_op(x, bitreverse(y))) -> logic_op(bitreverse(x), y)
bitreverse(logic_op(bitreverse(x), y)) -> logic_op(x, bitreverse(y))
bitreverse(logic_op(bitreverse(x), bitreverse(y))) -> logic_op(x, y) with multi-use
```

Reviewed By: goldstein.w.n

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

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

Users will be informed when non-POD is not packed using -Wall. This is
also consistent with GCC.

Fixes https://github.com/llvm/llvm-project/issues/60832
Differential Revision: https://reviews.llvm.org/D151162

PageMap is allocated with MAP_ALLOWNOMEM if there's no static buffer
left. So it can be failed and return nullptr without any assertion
triggered. Instead of crashing in the releaseToOSMaybe in the middle,
just return and let the program handles the page failure.

Reviewed By: cferris

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

This was originally added to preserve FMF on SETCC. Unfortunately,
it also incorrectly preserves nuw/nsw on ADD/SUB in some cases.

There's also no guarantee the new opcode is even the same opcode
as the original node.

This patch removes the code and adds code to explicitly preserve
FMF flags in the SETCC promotion function.

The other test changes are from nuw/nsw not being preserved. I
believe for all these tests it was correct to preserve the flags,
so we need new code to preserve the flags when possible. I'll post
another patch for that since it's a riskier change.

This should unblock D150769.

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

This enables unwinders to step past that frame on architectures that
don't use DWARF unwinding (such as armv7), e.g. when debugging. The
problem should theoretically be architecture-agnostic, but according to
https://discourse.llvm.org/t/51633/2 it gets masked on architectures
that use DWARF unwind info.

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

Reviewed By: efriedma, rnk

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

This fixes and GCC error. This was tested in D135787.

Currently, the method `GetAttributeAddressRanges` takes a DWARFRangeList as a
parameter, just to immediately clear it. The method also returns the size of
this list. Such an API was obfuscating the intent of the call sites (it's not
clear from the method name what it returns) and it was obfuscating redundant
checks on the size of the list.

This commit refactors the method to return the list and to also make the call
sites use the more explicit `IsEmpty` method.

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

RenderFrame() has several implementations, which was missed in
01cea39f.

Fix the one in sanitizer_symbolizer_markup.cpp.

Reported-by: gulfem

This patch is to remove the conversion of the actual argument that
is associated with the dummy argument specified with the IGNORE_TKR
directive.

Commit on behalf of @danielcchen

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

When looking for payload op replacements, rank-expanding InsertSliceOps of dynamically-typed tensors are now supported.

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

Reviewed By: aartbik

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

Add a helper function that computes if two SSA values have the same value, utilizing the `ValueBoundsOpInterface` infrastructure. Two SSA values have the same value, an equality bound of 0 can be derived for their subtraction.

The helper function can also be used to determine if two tensor dimension sizes are equal.

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

Reviewed By: vzakhari, jeanPerier

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

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

The inline history makes sure that we don't keep inlining due to mutual devirtualization. But this gets forgotten between inliner invocations.

So mark the inlined calls as noinline so we respect previous inline history decisions.

This overlaps with D121084, but they're not redundant since we may not inline completely through a child SCC, but we still want a cost multiplier when that happens.

See discussions in D145516.

Reviewed By: jmorse

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

This line has been misplaced since it was introduced in 2011 by
c26e4454.

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

There is no initialization of the data between allocation
and first getBeginLoc call.

allocation: llvm-project/clang/lib/AST/ASTContext.cpp:3022
use: llvm-project/clang/lib/AST/TypeLoc.cpp:222

Msan report https://reviews.llvm.org/P8306

Reviewed By: thurston

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

In some scenarios, a SELECT CASE could cause an error while lowering to FIR.
This was caused by a spurious extra branch added after the end statement.

Fixes #62726

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

[Clang] Switch from TransformExpr to TransformInitializer in places we need to revert initializer to it syntactic form for Sema

In some cases we are using TransformExpr instead of
TransformInitializer, this results in ExprWithCleanups being dropped and
we are not emitting a destructor as a result.

This fixes: https://github.com/llvm/llvm-project/issues/62818

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

Certain InsertSliceOps, that do not use elements from the destination, are treated like casts when looking for replacement ops. Such InsertSliceOps are typically rank expansions.

Tensors with dynamic shape are not supported at the moment.

Also adds test cases for the TrackingListener.

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

Since the scf.forall is now consumed by the fuse into
containing op, we need to return a handle to the new scf.forall.
This patch does that and also ensures that the new bbArg
added to the scf.forall is used in its body.

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

EarlyFPM cleans up the output of the frontend. This isn't necessary in post link pipelines as the pre link pipeline already ran this.

~0.4% savings in ThinLTO builds:
https://llvm-compile-time-tracker.com/compare.php?from=8a5d4eb775c644d8683f24817d44c510d2b853b7&to=3580252a2162eadca0da99f1eeaa112f74a0353d&stat=instructions:u

Reviewed By: tejohnson

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

Need to finalize the DIBuilder to avoid leak sanitizer errors
like this:

Direct leak of 48 byte(s) in 1 object(s) allocated from:
    #0 0x55c99ea1761d in operator new(unsigned long)
    #1 0x55c9a518ae49 in operator new
    #2 0x55c9a518ae49 in llvm::MDTuple::getImpl(...)
    #3 0x55c9a4f1b1ec in getTemporary
    #4 0x55c9a4f1b1ec in llvm::DIBuilder::createFunction(...)

For block arg locs a common case is no/uknown location (where the producer
signifies they don't care about blockarg location). Also avoid needing to
dynamically resize opnames during parsing.

Assumed to be post lazy loading change, so chose version 3.

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

Currently, the dialects precede the registered operations in the context object, which means that the latter is destroyed first. At the same time, Operation::~Operation dereferences the registered operation when destroying properties, which can cause use-after-free (e.g. if a dialect owns an op). This patch fixes that by changing the order of the members so that dialects come after registered operations.

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

We already have -print-on-crash which dumps the IR to stderr on a crash, but it's more useful to dump to a file.

Introduce -print-on-crash-path to dump the IR to a file.

Making -print-on-crash a string option is confusing if you only pass -print-on-crash and it swallows up the next command line arg, which is why this is a new option.

Perhaps we could retire the dump to stderr version if people don't use it, but not sure how much people find that useful.

Reviewed By: jamieschmeiser

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

# Darwin Sanitizers Stable ABI

We wish to make it possible to include the AddressSanitizer (ASan) runtime implementation in OSes and for this we need a stable ASan ABI. Based on previous discussions about this topic, our understanding is that freezing the present ABI would impose an excessive burden on other sanitizer developers and for unrelated platforms. Therefore, we propose adding a secondary stable ABI for our use and anyone else in the community seeking the same. We believe that we can define a stable ABI with minimal burden on the community, expecting only to keep existing tests running and implementing stubs when new features are added. We are okay with trading performance for stability with no impact for existing users of ASan while minimizing the maintenance burden for ASan maintainers. We wish to commit this functionality to the LLVM project to maintain it there. This new and stable ABI will abstract away the implementation details allowing new and nov...

Stacktraces should no longer show __asan_wrap_, but the "normal"
function name.

Reflect that in tests.