Perform the TryToSimplifyUncondBranchFromEmptyBlock() transform if
the block is empty except for ephemeral values. The ephemeral values
will be dropped in that case.

This makes sure that assumes don't block this transforms, as reported
in https://discourse.llvm.org/t/llvm-assume-blocks-optimization/71609.

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

This patch reverts the following commits:

    015cd317 (add missing HIDE_FROM_ABI)
    420a204d (add _LIBCPP_NO_CFI)
    31eeba3f (add __uninitialized_buffer)

It also reverts a small part of b935ab8e
which is required to make the stable_partition.pass.cpp test pass on GCC.

Some issues were pointed out in https://reviews.llvm.org/D152208 and
in https://reviews.llvm.org/D154017, so I am reverting this patch
until we have time to weigh the various solutions and get consensus
on the design of the API.

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

This reverts commit 0c545a44.

ARM libcall expansion was fixed in 160d7227

The ExpandLibcallResult result was a bitcast and not the direct call
result, so we couldn't find the chain. Use the new separate chain
return value instead.

If the libcall expansion requires use of the inserted call's result
chain, it's unreliable to query it from the main result. The call
lowering may have added additional casts or other obscuring operations
we don't want to parse through.

This is based on ideas from @nafi to:
 - use a branchless version of 'cmp' for 'uint32_t',
 - completely resolve the lexicographic comparison through vector
   operations when wide types are available. We also get rid of byte
   reloads and serializing '__builtin_ctzll'.

I did not include the suggestion to replace comparisons of 'uint16_t'
with two 'uint8_t' as it did not seem to help the codegen. This can
be revisited in sub-sequent patches.

The code been rewritten to reduce nested function calls, making the
job of the inliner easier and preventing harmful code duplication.

Reviewed By: nafi3000

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

CHPE metadata is used by ARM64EC/ARM64X PE files to provide metadata for
emulator/loader. Most of this metadata will need to be generated by LLD.

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

The SPIR-V spec does not specify the mangling for these variables, so
the conversion to SPIR-V should be flexible enough to allow adding a
custom prefix and suffix to the core name.

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



Signed-off-by: Victor Perez <victor.perez@codeplay.com>

Add the required options and macros to the compilation step for z/os.

Reviewed By: abhina.sreeskantharajan, fanbo-meng

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

Improve `tensor::createPadHighOp`: more static padding sizes when possible.

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

The same functionality is provided by `makeComposedFoldedAffineApply`.

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

* Use `create` instead of `createOrFold` for constant ops. Constants cannot be folded any further.
* Use `create` instead of `createOrFold` for ops that do not have a folder.
* Use C++ op builders that take an `int` instead of creating a `ConstantIndexOp`.
* Create `tensor::DimOp` instead of `linalg::createOrFoldDimOp` when it is certain that the operand is a tensor.

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

This caused asserts in some Android and Windows builds:

SelectionDAGNodes.h:1138: llvm::SDValue::SDValue(SDNode *, unsigned int):
Assertion `(!Node || !ResNo || ResNo < Node->getNumValues()) && "Invalid result number for the given node!"' failed.

See comment on https://github.com/llvm/llvm-project/commit/85bdea023f5116f789095b606554739403042a21

Also revert "HIP: Use frexp builtins in math headers"
which seems to depend on this change.

This reverts commit 85bdea02.
This reverts commit bf8e92c0.

This attempts to fold trees of add(ext(load p), shl(ext(load p+4)) into a
single load of twice the size, that we extract the bottom part and top part so
that the shl can start to use a shll2 instruction. The two loads in that
example can also be larger trees of instructions, which are identical except
for the leaves which are all loads offset from the LHS, including buildvectors
of multiple loads. For example:
sub(zext(buildvec(load p+4, load q+4)), zext(buildvec(load r+4, load s+4)))

Whilst it can be common for the larger loads to replace LDP instructions (which
doesn't gain anything on its own), the larger loads in buildvectors can help
create more efficient code, and prevent the need for ld1 lane inserts which can
be more expensive than continuous loads.

This creates a fairly niche, fairly large combine that attempts to be fairly
general where it is beneficial. It helps some SLP vectorized code to avoid the
use of the more expensive ld1 lane inserting loads.

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

This patch adds a thunk for Thumb long branch on V6-M for eXecute Only.

Note that there is currently no support for a position independant and
eXecute Only V6-M long branch thunk

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

During legalization, we can end up with shuffles that are identity masks, so
act like extract_subvector, but do not simplify to extract_subvector. This
adjusts the profitability heuristic in foldExtractSubvectorFromShuffleVector to
allow identity vectors that do not start at element 0. Undef masks elements are
excluded as it can be more useful to keep the undef elements.

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

This reverts commit 19b1d3bd.

Both the commit and the review are missing a patch description.

This work adds `mbarrier.test.wait` and `mbarrier.test.wait.shared` Ops in NVVM dialect. Since they are already implemented in the LLVM kernel, it only calls createIntrinsicCall.

Reviewed By: qcolombet

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

`mbarrier.arrive` returns token. This PR adds result to these ops.

Reviewed By: qcolombet

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

While looking at https://github.com/llvm/llvm-project/issues/61955
I noticed that when we send qLaunchGDBServer we check that we got a response
but not what kind of response it was.

I think this was why the bug reporter saw:
(lldb) run
error: invalid host:port specification: '[192.168.64.2]'

The missing port is because we went down a path we only should have
chosen if the operation succeeded. Since we didn't check, we went ahead
with an empty port number.

To test this I've done the following:
* Make a temporary copy of lldb-server.
* Run that as a platform.
* Remove the copy.
* Attempt to create and run a target.

This fails because the running lldb-server will try to invoke itself
and it no longer exists.

Reviewed By: jasonmolenda

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

The first line of the code snippet we print is potentially lower than
the caret line, so handle that case.

Fixes #63524

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

Since an immediate invocation is a full expression itself - it requires
an additional ExprWithCleanups node, but it can participate to a bigger
full expression which actually requires cleanups to be run after.

Thanks @ilya-biryukov for helping reducing the reproducer and confirming
that the analysis is correct.

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

Reviewed By: ilya-biryukov

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

We're in favor of writeToOutput.

If `fseek` is used with 0 position and SEEK_SET it sets the position
to the start of the file. This should not cause FEOF (end of file) error.
The case of an empty file is not handled for simplification.
It is not exactly defined in what cases `fseek` produces the different
error states. Normally feof should not happen at all because it is
possible to set the position after the end of file, but previous tests
showed that still feof (and any other error cases) can happen.

Reviewed By: donat.nagy

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

API in ASTUnit.cpp

writeFileAtomically is going to be deprecated, in favor of
writeToOutput.

In a very rare case that mmap call fails, we'll at least get a message
instead of segfault.

Reviewed By: rafauler, Amir
Differential Revision: https://reviews.llvm.org/D154056

Reviewed By: rafauler, Amir
Differential Revision: https://reviews.llvm.org/D154056

We're going to deprecate the writeFileAtomically API, in favour of
writeToOutput.

This reverts commit 37114036.

The output of mbcnt does not depend on other active lanes, and hence it is not
convergent. The original change was made as a possible fix for

https://github.com/ROCm-Developer-Tools/HIP/issues/3172

But changing mbcnt does not fix that issue.

Reviewed By: ruiling, foad, yaxunl

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

Scalar FMUL, FMULX instructions perform better or the same compared to indexed
FMUL, FMULX.

For example, the Arm Cortex-A55 Software Optimization Guide lists the following
instructions with a throughput of 2 IPC:
 - "FP multiply" FMUL
 - "ASIMD FP multiply" FMULX

whereas it lists the following with a throughput of 1 IPC:
 - "ASIMD FP multiply, by element" FMUL, FMULX

The Arm Cortex-A510 Software Optimization Guide, however, does not separately
list "by element" variants of the "ASIMD FP multiply" instructions, which are
listed with the same throughput as the non-ASIMD ones.

Fixes #60817.

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

When the analysis of hlfir.region_assign determined that the LHS region
evaluation may be impacted by the assignment effects, all LHS must be
fully evaluated and saved before any assignment is done.

This patch adds TemporaryStorage variants to save address, including
vector subscripted entities addresses whose shape must be saved.
It uses the DescriptorStack runtime to deal with complex cases inside
forall. For the sake of simplicity, this is also used for vector
subscripted LHS outside of foralls (each element address is saved as
a descriptor on this stack. This is a bit suboptimal, but it is a safe
start that will work with all kinds of type (polymorphic, PDTs...)
without further work). Another approach would be to saved only the
values that are conflicting in the LHS computation, but this would
require a much more complex analysis of the LHS region DAG.

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

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