Msan needs noundef consistency between interface and implementation. If
we call C++ from C we can have noundef on C++ side, and no noundef on
caller C side, noundef implementation will not set TLS for return value,
no noundef caller will expect it. Then we have false reports in msan.

The workaround could be set TLS to zero even for noundef return values.
However if we do that always it will increase binary size by about 10%.
If we do that selectively we need to handle "address is taken"
functions, any non local functions, and probably all function which have
musttail callers. Which is still a lot.

The existing implementation of HasStrictReturn refers to C standard as
the reason not enforcing noundef. I believe it applies only to the case
when return statement is omitted. Testing on Google codebase I never see
such cases, however I've see tens of cases where C code returns actual
uninitialized variables, but we ignore that it because of "omitted
return" case.

So this patch will:
1. fix false-positives with TLS missmatch.
2. detect bugs returning uninitialized variables for C as well.
3. report "omitted return" cases stricter than C, which is already a
   warning and very likely a bug in a code anyway.

Reviewed By: kda

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

SMLoc uses std::nullopt_t, so it should include optional rather than
None.h.

This is part of an effort to migrate from llvm::Optional to
std::optional:

https://discourse.llvm.org/t/deprecating-llvm-optional-x-hasvalue-getvalue-getvalueor/63716

Since tosa.pad is lowered strictly to artih and tensor ops, move
ConvertPad from TosaToLinalg to TosaToTensor, benefitting non-Linalg
Tosa targets. TensorToLinalg exists, and is trivial, so nothing is lost.

Signed-off-by: Ramkumar Ramachandra <r@artagnon.com>

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

This is part of an effort to migrate from llvm::Optional to
std::optional:

https://discourse.llvm.org/t/deprecating-llvm-optional-x-hasvalue-getvalue-getvalueor/63716

This patch mechanically replaces None with std::nullopt where the
compiler would warn if None were deprecated.  The intent is to reduce
the amount of manual work required in migrating from Optional to
std::optional.

This is part of an effort to migrate from llvm::Optional to
std::optional:

https://discourse.llvm.org/t/deprecating-llvm-optional-x-hasvalue-getvalue-getvalueor/63716

This is part of an effort to migrate from llvm::Optional to
std::optional:

https://discourse.llvm.org/t/deprecating-llvm-optional-x-hasvalue-getvalue-getvalueor/63716

These .cpp files do not use llvm::None anymore.

Since these are not header files, we can remove them pretty safely
without deprecating them first.

The pass was not checking for uninitialized states due to dead code.
This patch also makes LLVMFuncOp correctly return a null body when it is
external.

Fixes #58807

Depends on D139388

Reviewed By: rriddle

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

Reviewed By: rriddle

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

This patch implements shouldFoldSelectWithIdentityConstant for RISCV. It would try to generate vmerge after the binary instruction and let them folded to maksed instruction later.

Reviewed By: craig.topper

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

Reviewed By: rriddle

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

Reviewed By: mgehre-amd

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

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

This was added in 29e2d946 and likely never worked in a useful
way.

The test added for it fails when converted to opaque pointers, since
the lifetime intrinsic now directly uses the address. The code was
only trying to handle a user indirectly through a bitcast
instruction. That would never have been useful; a bitcast of a global
value would be folded to a ConstantExpr cast.

I also don't understand why it was special casing use_empty on the
cast. Relax the check to be either BitCastOperator or
AddrSpaceCastOperator. In practice, BitCastOperator won't appear
today.

I believe the change in parallel_deletion_cg_update is a correct
improvement but I didn't fully follow it. .omp_outlined..0 is used in
a constant expression cast to a call which ends up getting deleted.

Reviewed By: craig.topper

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

On Windows rebuilding the binary isn't enough to unload it
on progrem restart. But the assumption of the test is that on
program re-run LLDB destroys and replaces the old module with
the newly built version. One will have to try hard to evict the
module from the ModuleList (possibly including a call to
`SBDebugger::MemoryPressureDetected`.

See D138724

Implicit cast between char* and StringRef when writing sections.

Reproduce:
```
$> llvm-objcopy --dump-section=name=name.data out.wasm
$> llvm-objcopy --remove-section=name out.wasm out_no_name.wasm
$> llvm-objcopy --add-section=name=name.data out_no_name.wasm out_new_name.wasm

```

Reviewed By: dschuff

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

At import time, these calls to `logging.debug()` implicitly call `logging.basicConfig` (https://docs.python.org/3/library/logging.html#logging.basicConfig), setting logging config for the whole project which cannot then be overwritten later. For instance, consider the following test script:

```
import logging
import jax

logger = logging.getLogger(__name__)
logging.basicConfig(level=logging.INFO)
logger.info('info')
```
This should log out `'info'`, but because when `import jax` is called, this `_mlir_lib/__init__.py` file is run and a `logging.debug` is called, calling `logging.basicConfig`, my `logging.basicConfig(level=logging.INFO)` does nothing.

Fix: instead of using root logger, use a module level logger.

Found in this issue: https://github.com/google/jax/issues/12526

Reviewed By: stellaraccident

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

D135833, lowerSelect: (select C, -1/0, X) -> or/and
Keep (select c, 0/-1, X), thus making better use of lowerSelect to eliminate branch instructions.

Reviewed By: craig.topper

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

Revert "[mlir][sparse] Refactoring: abstract sparse tensor memory scheme into a SparseTensorDescriptor class."

This reverts commit 8a7e69d1.

This broke the windows mlir buildbot: https://lab.llvm.org/buildbot/#/builders/13/builds/29257

This change cleans up the conversion pass re the "dim"-vs-"lvl" and "sizes"-vs-"shape" distinctions of the runtime. A quick synopsis includes:

* Adds new `SparseTensorStorageBase::getDimSize` method, with `sparseDimSize` wrapper in SparseTensorRuntime.h, and `genDimSizeCall` generator in SparseTensorConversion.cpp
* Changes `genLvlSizeCall` to perform no logic, just generate the function call.
* Adds `createOrFold{Dim,Lvl}Call` functions to handle the logic of replacing `gen{Dim,Lvl}SizeCall` with constants whenever possible. The `createOrFoldDimCall` function replaces the old `sizeFromPtrAtDim`.
* Adds `{get,fill}DimSizes` functions for iterating `createOrFoldDimCall` across the whole type. These functions replace the old `sizesFromPtr`.
* Adds `{get,fill}DimShape` functions for lowering a `ShapedType` into constants. These functions replace the old `sizesFromType`.
* Changes the `DimOp` rewrite to do the right thing.
* Changes the `ExpandOp` rewrite to compute the proper expansion size.

Depends On D138365

Reviewed By: aartbik

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

Breaks cmake regeneration for me:
```
CMake Error: install(EXPORT "LLVMExports" ...) includes target "omptarget.rtl.cuda.nextgen" which requires target "PluginInterface" that is not in any export set.
CMake Error: install(EXPORT "LLVMExports" ...) includes target "omptarget.rtl.x86_64.nextgen" which requires target "PluginInterface" that is not in any export set.
```

This reverts commit 08c4081b.

This patch uses `add_llvm_library` to build the target `PluginInterface` since it can handle LLVM dependences much better. One temporary drawback of using this is that currently LLVM CMake macro doesn't support object libraries very well (there was a try a couple years ago but it was reverted later https://github.com/llvm/llvm-project/commit/29e57229497711a3a294f437b59afa6ddc36a3d8). After switching to that, `CXX_VISIBILITY_PRESET` can not be set correctly, which can cause runtime error that a function call from one plugin could go to another. As a consequence, `PluginInterface` is built as a static library for now. I have asked the question in CMake community (https://discourse.cmake.org/t/set-target-properties-doesnt-work-properly/7016). Once that issue is solved, I'll switch it back to object library. It is not necessarily too bad to use static library, especially `BUILDTREE_ONLY` is already set such that `PluginInterface.a` will not be installed.

Reviewed By: jhuber6

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

These were early exiting if we replaced a sequence with a 2 instruction
sequence since that is the best we could do. All the later optimizations
only occur if the sequence is more than 2 instructions so this wasn't a
functional check.

At best it helps the compiler generate better code, but I don't think
that was analyzed when it was added. Remove it to simplify the code.

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

This reverts commit 200007ec.

This reverts commit aacf17aa.

Fixed by using the right register class for the movk.

This is the initial commit for -Wunsafe-buffer-usage, a warning that helps
codebases (especially modern C++ codebases) transition away from raw buffer
pointers.

The warning is implemented in libAnalysis as it's going to become a non-trivial
analysis, mostly the fixit part where we try to figure out if we understand
a variable's use pattern well enough to suggest a safe container/view
as a replacement. Some parts of this analsysis may eventually prove useful
for any similar fixit machine that tries to change types of variables.

The warning is disabled by default.

RFC/discussion in https://discourse.llvm.org/t/rfc-c-buffer-hardening/65734

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

DynamicLoaderDarwinKernel::SearchForKernelNearPC() searches for a
Darwin kernel mach-o header starting at $pc and working backwards,
stopping on the first memory read error encountered.  The kernel,
and the kexts linked in to the kernel, have grown over the years
and the original 32MB scan limit is giving a high chance of failing
to find the kernel if we're in a random kext.

In non-kernel environments, firmware and bare board typically, we
will hit a memory read error on an unmapped page quickly so this
doesn't add a lot of random memory read requests in those environments.

We only check at one megabyte boundaries, so worst case this is 128
reads at the start of a gdb-remote connection.  The check for a
memory read error & stopping was a more recent addition (a few years
ago), so I kept the scan region a bit small.

Reviewed By: ThomasRaoux

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

This reverts commit 7358c29a.

This broke an upstream builder:
https://lab.llvm.org/buildbot/#/builders/16/builds/39356