The LastChange can be MBB->end(), so it is not valid to dereference it for
printing. Fix the DEBUG statement to check for end() and handle it specially.

D155499 fixed an issue with implicit continuations. The fixes included a
nested parenthesis check during definition of a macro which is then
carried over in the scanner state.

This leads to the following corner case to fail:

subroutine foo(a, d)
  implicit none
  integer :: a
  integer :: d

   ! An implicit continuation won't be considered unless
   ! the definition of "bar" above is removed/commented
   call sub(1,
     2)
end subroutine foo

The definition of bar is indeed unbalanced but it is not even used in
the code, so it should not impact whether we apply implicit continuation
in the expansion of sub.

This change aims at addressing this issue by removing the balance check
and constraining a bit more when we consider implicit continuations:
only when we see a left parenthesis after a function-like macro, not a
object-like macro. In this case I think it is OK to (unconditionally)
implicitly continue to the next line in search of the corresponding
right parenthesis. This is, to my understanding, similar to what the C
preprocessor would do according to the description in [1].

[1] https://www.spinellis.gr/blog/20060626/

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

This new pattern allows us to simplify the dealloc result value (by replacing
it with a constant 'true') and to trim the 'memref' operand list when we know
that all retained memrefs alias with one in the 'memref' list that has a
constant 'true' condition. Because the conditions of aliasing memrefs are
combined by disjunction, we know that once a single constant 'true' value is in
the disjunction the remaining elements don't matter anymore. This complements
the RemoveDeallocMemrefsContainedInRetained pattern which removes values from
the 'memref' list when static information is available for all retained values
by also allowing to remove values in the presence of may-aliases, but under
above mentioned condition instead.
The BufferDeallocation pass often adds dealloc operations where the memref and
retain lists are the same and all conditions are 'true'. If the operands are
all function arguments, for example, they are always determined to may-alias
which renders the other patterns invalid, but the op could still be trivially
optimized away. It would even be enough to directly compare the two operand
lists and check the conditions are all constant 'true' (plus checking for the
extract_strided_metadata operation), but this pattern is a bit more general and
still works when there are additional memrefs in the 'memref' list that actually
have to be deallocated (e.g., see regression test).

Reviewed By: springerm

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

It looks like current support for DWARFv5 is good enough to have
output verification. This patch removes DWARFv5 restriction for
output verification.

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

Add a BackendRemarkConsumer class, responsible for handling diagnostics
received from LLVM. The diagnostics being information on middle and
backend passes used or not used.

Clang by default has all remarks ignored but manually sets the severity of
`R_Group` to visible(`clang::diag::clang::Severity::Remark`). This patch does
the same for Flang.

Depends on D157410. That patch adds the R family of options to
`FlangOption` and `FC1Option` in
`clang/include/clang/Driver/Options.td`

Reviewed By: awarzynski

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

Since https://reviews.llvm.org/D158119, many boxes lowered via HLFIR are
reboxed with better lower bounds information after they are declared.

For the loop versioning pass to support FIR lowered via HLFIR, it needs
to dereference fir.rebox operations to figure out that the variable was
a function argument.

I decided to modify the existing dereferencing of fir.declare so that
the declared/reboxed value is used in the versioned loop instead of the
function argument. This makes it easier for the improved lower bounds
information to be accessed. In doing this, I changed ArgInfo to store
ArgInfo::arg by value instead of by pointer because mlir::Value has
value-type semantics.

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

Member functions and static variable definitions may use typedefs that
are private in the global context, but fine in the class context.

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

This follows from D155306.

Loads and stores of 128-bit tiles have been confirmed to work in the
`load-store-128-bit-tile.mlir` integration test. However, there is
currently a bug in QEMU (see: https://gitlab.com/qemu-project/qemu/-/issues/1833)
which means this test produces incorrect results (a patch for this issue
is available but not yet in any released version of QEMU). Until a
fixed version of QEMU is available the integration test is expected to fail.

Reviewed By: c-rhodes, awarzynski

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

The transform 'foldSingleElementStore' can be applied to scalable
vector types if the index is less than the minimum number of elements.

Reviewed By: dmgreen, nikic

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

This patch adds the Zvfhmin extension for clang.

Reviewed By: craig.topper, michaelmaitland

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

[Coroutines] [CoroElide] Don't think exceptional terminator don't leak coro handle unconditionally any more

Close https://github.com/llvm/llvm-project/issues/59723.

The fundamental cause of the above issue is that we assumed the memory
of coroutine frame can be released by stack unwinding automatically
if the allocation of the coroutine frame is elided. But we missed one
point: the stack unwinding has different semantics with the explicit
coroutine_handle<>::destroy(). Since the latter is explicit so it shows
the intention of the user. So we can blame the user to destroy the
coroutine frame incorrectly in case of use-after-free happens. But we
can't do so with stack unwinding.

So after this patch, we won't think the exceptional terminator don't
leak the coroutine handle unconditionally. Instead, we think the
exceptional terminator will leak the coroutine handle too if the
coroutine is leaked somewhere along the search path.

Concretely for C++, we can think the exceptional terminator is not
special any more. Maybe this may cause some performance regressions.
But I've tested the motivating example (std::generator). And on the
other side, the coroutine elision is a middle end opitmization and not
a language feature. So we don't think we should blame such regressions
especially we are correcting the miscompilations.

This adds some more extensive test coverage for fadd/fsub through global isel,
switching the opcodes to use the more complete ActionDefinitions to handle more
cases.

For most fp16 vector ops, we could promote it to fp32 vector when zvfhmin is enable but zvfh is not.
But for nxv32f16, we need to split it first since nxv32f32 is not a valid MVT.

Reviewed By: michaelmaitland

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

This patch supports Zvfhmin for RISCV codegen.

Reviewed By: michaelmaitland

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

Allows more easily to manage custom additions and removals.

This works makes links more readable in NVVM dialect's tablegen file.

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

These are broken out from https://reviews.llvm.org/D156658, which it now seems obvious isn't the right way to solve the non-convergence.

Instead, my plan is to address the non-convergence through pointer value widening, but the exact way this should be implemented is TBD. In the meantime, I think there's value in getting these repros submitted to record the current undesirable behavior.

Reviewed By: ymandel, xazax.hun

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

When compiling compiler-rt with -fsanitize=undefined and running testcases you
end up with the following warning:

UBSan: floatsidf.c:32:9: negation of -2147483648 cannot be represented in type 'si_int' (aka 'long'); cast to an unsigned type to negate this value to itself

The same kind of pattern exists in floatsisf.c

This was found in an out of tree target.

Reviewed By: MaskRay

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

Currently BenchmarkRunner.cpp stores the return code of recvmsg as
size_t. Not only is this incorrect (as recvmsg returns ssize_t), but it
also makes the error code check after the statement completely irrelvant
as it checks if the number of bytes read is greater than zero (which
will always be true for an unsigned type).

This was an oversight in D146872, where function calls with tuple type
was not covered. This commit fixes this.

Reviewed By: craig.topper

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

Specification PR: riscv-non-isa/rvv-intrinsic-doc#256

Reviewed By: craig.topper

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

This is in preparation for using the same convergence verifier for both LLVM IR
and Machine IR.

Reviewed By: yassingh

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

This revision adds LLVM_MARK_AS_BITMASK_ENUM to HoistingKind to avoid static_cast when performing bitwise operations.

Reviewed By: mehdi_amini

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

Fix copied from https://reviews.llvm.org/D156946 but with a legit test case that triggers the bug.

Reviewed By: aartbik

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

It is surprising for the user that only some fields were honored.

Also make the FrozenRewritePatternSet a shared_ptr<const T>.

Fixes #64543

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

These methods are needed for use with `Diagnostic::operator<<` etc.

The definitions follow the pattern of `Diagnostic::str` by simply wrapping the underlying `print(raw_ostream)` method.  Although there is some overhead for constructing the `std::string`, this seems like the overall most-efficient option: since this overhead only occurs on the error path (under the current intended usage).  An alternative approach would be to have one method construct a `Twine` directly, and then have the print method pass the twine to the stream; however, that would mean introducing the overhead of twine construction on the common/happy path of simply printing things out.

Reviewed By: aartbik

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

These new methods help clean up some code for doing LvlExpr-analysis during DimExpr-inference.

Reviewed By: aartbik

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

For many interesting process-symbols setups we need access to the LLJIT instance
(e.g. to mangle symbols, or inspect the process triple). This patch updates the
ProcessSymbolsJITDylibSetupFunction to take an LLJIT reference and return the
process symbols JITDylib, which the callback must now create.

According to https://www.ibm.com/docs/en/xl-c-and-cpp-linux/16.1.1?topic=functions-vec-promote, the index should be input modulo the number of elements in the vector. When the type is `vector char`, the number of elements should be 16.

Reviewed By: qiucf

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

This implements the proposal from
https://discourse.llvm.org/t/adding-flang-specific-header-files-to-clang/72442/6
Since ISO_Fortran_binding.h is supposed to be included from users'
C/C++ codes, it would better have no dependencies on other header
files.

Reviewed By: PeteSteinfeld

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

This is a quick fix forward to get bots green again.

Prior to this change, stack realignment was achieved using the SRLI/SLLI
instructions in two steps. With this patch, stack realignment is
optimized using a single `BSTRINS` instruction.

Reviewed By: SixWeining, xen0n

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

The test does not require asserts. So it can't check the stats.

This reverts commit f2583f3a.

There is a large body of non-conforming C-like code using format strings
like this:

  #define PRIuS "zu"
  void h(size_t foo, size_t bar) {
    printf("foo is %"PRIuS", bar is %"PRIuS, foo, bar);
  }

Rejecting this code would be very disruptive. We could decide to do
that, but it's sufficiently disruptive that I think it requires
gathering more community consensus with an RFC, and Aaron indicated [1]
it's OK to revert for now so continuous testing systems can see past
this issue while we decide what to do.

[1] https://reviews.llvm.org/D153156#4607717

This reverts commit ab531091 which was
commited by mistake.

Reviewed By: aartbik

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