MachineOutliner may outline a "patchable-function-entry" function whose body has
a TargetOpcode::PATCHABLE_FUNCTION_ENTER MachineInstr. This is incorrect because
the special code sequence must stay unchanged to be used at run-time.
Avoid outlining PATCHABLE_FUNCTION_ENTER. While here, avoid outlining FENTRY_CALL too
(which doesn't reproduce currently) to allow phase ordering flexibility.

Fixes #52635

Reviewed By: paquette

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

Add lldb support for a Mach-O "load binary" LC_NOTE which provides
a UUID, load address/slide, and possibly a name of a binary that
should be loaded when examining the core.

struct load_binary
{
    uint32_t version;        // currently 1
    uuid_t   uuid;           // all zeroes if uuid not specified
    uint64_t load_address;   // virtual address where the macho is loaded, UINT64_MAX if unavail
    uint64_t slide;          // slide to be applied to file address to get load address, 0 if unavail
    char     name_cstring[]; // must be nul-byte terminated c-string, '\0' alone if name unavail
} __attribute__((packed));

Differential Revision: https://reviews.llvm.org/D115494
rdar://85069250

This patch makes the process of clauses of atomic directive more clear
and preparation for the support for `atomic compare capture`.

Reviewed By: jdoerfert

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

One of the uses of `LTOCodeGenerator` is to take it as a middle+back end. Sometimes
it is very helpful to access, especially get information from the optimized module.
If the information can be changed in optimization, it cannot be get before the
module is added to `LTOCodeGenerator`. This patch adds a function
`LTOCodeGenerator::getMergedModule` to access the `MergedModule`.

Reviewed By: steven_wu

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

This is a post-commit fix for https://reviews.llvm.org/D114338 which was landed as
https://reviews.llvm.org/rG050cc1cd6e6882eadba6e5ea7b588ca0b8aa1b12

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

explores various sparsity combinations of
the SDMM kernel and verifies that the computed
result is the same for all cases

Reviewed By: bixia

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

This reverts commit bbfaf0b1.

Post commit review noted a case where my manual update lost intentional check lines.  Given I've abandoned the motivating patch, I'm just reverting the autogen prep.

This reverts commit 34696e65.

A test is crashing on the mlir-nvidia bot.

The gn script for lld's COFF lib adds an unnecessary dependency on llvm/lib/DebugInfo/Symbolize. There is no such dependency in lld/COFF/CMakeLists.txt. This can be safely removed.

Reviewed By: phosek, thakis

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

Followup to D114934

Add convertFromMLIRSparseTensor to the supporting C shared library to convert
SparseTensorStorage to COO-flavor format.

Add Python routine sparse_tensor_to_coo_tensor to convert sparse tensor storage
pointer to numpy values for COO-flavor format tensor.

Add a Python test for sparse tensor output.

Reviewed By: aartbik

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

StructuredDataImpl ownership semantics is unclear at best. Various
structures were holding a non-owning pointer to it, with a comment that
the object is owned somewhere else. From what I was able to gather that
"somewhere else" was the SBStructuredData object, but I am not sure that
all created object eventually made its way there. (It wouldn't matter
even if they did, as we are leaking most of our SBStructuredData
objects.)

Since StructuredDataImpl is just a collection of two (shared) pointers,
there's really no point in elaborate lifetime management, so this patch
replaces all StructuredDataImpl pointers with actual objects or
unique_ptrs to it. This makes it much easier to resolve SBStructuredData
leaks in a follow-up patch.

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

* Generalizes passes linalg-detensorize, linalg-fold-unit-extent-dims, convert-elementwise-to-linalg.
* I feel that more work could be done in the future (i.e. make FunctionLike into a proper OpInterface and extend actions in dialect conversion to be trait based), and this patch would be a good record of why that is useful.
* Note for downstreams:
  * Since these passes are now generic, they do not automatically nest with pass managers set up for that.
  * If running them over nested functions, you must nest explicitly. Upstream has adopted this style but *-opt still has some uses of implicit pipelines via args. See tests for argument changes needed.

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

Adapt the LinalgStrategyVectorizationPattern pass to apply the vectorization patterns in two stages. The change ensures the generic pad tensor op vectorization pattern does not run too early. Additionally, the revision adds the transfer op canonicalization patterns to the set of applied patterns, since they are needed to enable efficient vectorization for rank-reduced convolutions.

Reviewed By: nicolasvasilache

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

We had previously been using a different workaround for pretending that
we were inside a system header, however it had some undesirable effects
on dependency parsing for build systems, as explained in [1].

This patch changes the workaround to use `#pragma GCC system_header`,
which shouldn't suffer from the same issue. Unfortunately, it is a lot
more verbose. The issue is that `#pragma GCC system_header` is ignored
when we are inside a source file, so we have to create a header just for
the sake of using it. IMO this seems like an artificial restriction
without much benefit, but investigating that is a different story.
For now, this should at least solve build system problems at the
cost of some readability.

[1]: https://reviews.llvm.org/D95972#3178968

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

A small collection of utils called osutils has been added. These utils
are now used in loader tests instead of the equivalent entrypoints.
The loader can now be built and tested without depending on any entrypoint.
In a follow up change, the relevent entrypoints will be updated to use the
newly added osutils.

Reviewed By: lntue, michaelrj

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

I noticed we weren't propagating tail flags on calls when
FortifiedLibCallSimplifier.optimizeCall() was replacing calls to runtime
checked calls to the non-checked routines (when safe to do so). Make
sure to check this before replacing the original calls!

Also, avoid any libcall transforms when notail/musttail is present.

PR46734
Fixes: https://github.com/llvm/llvm-project/issues/46079

Reviewed By: jdoerfert

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

This patch provides a draft overlay to support compilation of llvm libc with Bazel.

Tested on linux x86-64 with
```
cd git/llvm-project/utils/bazel
bazelisk-linux-amd64 build --sandbox_base=/dev/shm --config=generic_clang @llvm-project//libc:all
```

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

This reverts commit e286fefa since
the issue affecting the sanitizer-ppc64le-linux builder is resolved.

LiveRangeEdit::allUsesAvailableAt checks that VNI at use is the same
as at the original use slot. However, the VNI can be the same while
a specific subrange needed for use can be dead at the new index.

This patch adds subrange liveness check if there is a subreg use.

Fixes: SWDEV-312810

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

This is an attempt to address 458ead66
by better matching the previous configuration.

This commit should fix a heap-use-after-free bug that was caught by the
sanitizer bot.

The issue is that we were reading memory from a second target into a
`SBData` object in Python, that was passed to lldb's internal
`ScriptedProcess::DoReadMemory` C++ method.

The ScriptedPythonInterface then extracts the underlying `DataExtractor`
from the `SBData` object, and is used to read the memory with the
appropriate address size and byte order.

Unfortunately, it seems that even though the DataExtractor object was
still valid, it pointed to invalid, possibly garbage-collected memory
from Python.

To mitigate this, the patch uses `SBData::SetDataWithOwnership` to copy
the pointed buffer to lldb's heap memory which prevents the
use-after-free error.

rdar://84511405

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



Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>

This patch introduces a new method to SBData: SetDataWithOwnership.

Instead of referencing the pointer to the data, this method copies the
data buffer into lldb's heap memory.

This can prevent having the underlying DataExtractor object point to
freed/garbage-collected memory.

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



Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>

These are the ones my first round of scripting couldn't handle that required a bit of manual messaging.  This should be the last batch in llvm-check.

If the gather node is a mix of undefvalues and exractelement
instructions, need to take the ordering for such nodes into account too.
It allows to reorder some (sub)trees and remove some extra shuffles,
improving overall vectorization.
Also, outlined common functionality into a separate function.

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

Done in advance of D115387.  These are all the ones which my local script could handle, there's a couple more which need manual updates.

Due to the differences between the types of long double, this function
is effectively three functions in one. This patch adds basic support for
the types of long double, although it's just using the fast path and the
fallback for the moment. I still need to implement a version of
Eisel-Lemire for performance, but the existing algorithms should be
correct.

Reviewed By: sivachandra, lntue

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

This would allow sharing the LiveRangeStageManager between different
RegAllocEvictionAdvisors. One scenario is for ML training, where we want
to capture what the default advisor would do, for bootstrapping (speeds
up training).

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

In the multi-threaded case, if a thread hits an error, we mimick
LLVMContext's behavior of reporting the error and exit-ing. However,
this doesn't cleanly join the other threads, so depending on how fast
the process exits, other threads may report 'terminate called without an
active exception'.

To avoid this non-determinsim, and without introducing a more complicated
design, we just report the error, but not exit early. We do track whether
we hit errors and exit(1) after joining.

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

As noted on D115547

Reviewed By: frasercrmck, simoll

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

The idea is to make scanRelocations mark some actions are needed (GOT/PLT/etc)
and postpone the real work to postScanRelocations. It gives some flexibility:

* Make it feasible to support .plt.got (PR32938): we need to know whether GLOB_DAT and JUMP_SLOT are both needed.
* Make non-preemptible IFUNC handling slightly cleaner: avoid setting/clearing sym.gotInIgot
* -z nocopyrel: report all copy relocation places for one symbol
* Make parallel relocation scanning possible (if we can avoid all stateful operations and make Symbol attributes atomic), but parallelism may not be the appealing choice
* Make GOT deduplication feasible

Since this patch moves a large chunk of code out of ELFT templates. My x86-64
executable is actually a few hundred bytes smaller.

For ppc32-ifunc-nonpreemptible-pic.s: I remove absolute relocation references to non-preemptible ifunc
because absolute relocation references are incorrect in -fpie mode.

Reviewed By: peter.smith, ikudrin

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

As noted on D115547

Sets LLVM_ENABLE_CURL to OFF by default to avoid accidental inclusion of libcurl in builds which do not override the default.

Reviewed By: thakis

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

Expression guraded in loop entry can be folded prior to comparison. This patch
proceeds D107353 and makes LIR able to deal with nested for-loop.

Reviewed By: qianzhen, bmahjour

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