This is follow-up of D150107.

On some platforms, std::abs may inadvertently pull in a math library.
This patch replaces its use in the new loop collapse code with
a no thrills in-situ implementation.

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

With this fix, when encountering an out-of-range uimm8 operand, the code
now triggers an appropriate error message, clearly indicating that the
immediate value must be an integer within the range of 0 to 255.

This patch adds copy/move assignment operator to the class which has user-defined copy/move constructor.

Reviewed By: tahonermann, NoQ, aaronpuchert

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

Tag selection for global variables is sequential, starting at a
pseduo-ish seed that's based on the hash of the file name.

Previously, it was possible for a global to be assigned a tag in the
range [1,15]. If the global's size was not a multiple of granules (i.e.
`size % 16 != 0`), then the last granule of the global would be assigned
a short granule tag as well.

If the real memory tag of the global (e.g. '04') happened to collide
with the short granule tag (e.g. '04'), then __hwasan_check would
see that the memory tag matched the short granule tag, and dutifully
assume (in this fast check) that everthing is okay.

Unfortunately, if you tried to access the [5,15]th byte, you never get
to the short granule check. This means you miss intra-granule overflows
on the last granule of a global, if said global was assigned a real
memory tag in the range [1,15].

This causes flakiness in certain global tests, if the SHA of the
filename changes between runs.
...

This patch implements a new clang driver flag -fsafe-buffer-usage-suggestions
which allows turning the smart suggestion machine on and off (defaults to off).
This is valuable for stability reasons, as the machine is being rapidly improved\
and we don't want accidental breakages to ruin the build for innocent users.
It is also arguably useful in general because it enables separation of concerns
between project contributors: some users will actively update the code to
conform to the programming model, while others simply want to make sure that
they aren't regressing it. Finally, there could be other valid reasons to
opt out of suggestions entirely on some codebases (while continuing to enforce
-Wunsafe-buffer-usage warnings), such as lack of access to hardened libc++
(or even to the C++ standard library in general) on the target platform.

When the flag is disabled, the unsafe buffer usage analysis is reduced to
an extremely minimal mode of operation that contains virtually no smarts:
not only it doesn't offer automatic fixits, but also textual suggestions
such as "change the type of this variable to std::span to preserve bounds
information" are not displayed, and in fact the machine doesn't even try
to blame specific variables in the first place, it simply warns on
the operations and leaves everything else to the user. So this flag turns off
a lot more of our complex machinery than what we already turn off in presence
of say -fno-diagnostic-fixit-info.

The flag is discoverable: when it's off, the warnings are accompanied by a note:
telling the user that there's a flag they can use.

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

This helps catch segfaults and OOB.

Reviewed By: aartbik, Peiming

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

One shot bufferization does not support bufferizing the cast between unranked tensors. To prevent the crash, we can check the compatibility of the result type in advance. Reported in https://github.com/llvm/llvm-project/issues/62369.

Reviewed By: springerm

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

Makes these cases work with assumes.

The constant folder for tosa.mul produces a tensor attribute whose type
may not match the result type of the operation when broadcasting is
needed. This results in a tosa.const op whose attribute's type does not
match the type of the const op.
This change explicitly expands the attribute to the expected result
type.

Reviewed By: eric-k256, jpienaar

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

This reverts commit 611fb179.

Broken tests

The size of a full ObjC MethodName can vary somewhat, but it is
computable ahead of time.

Using a reasonably sized ObjC application, this actually improves the
time it takes to initialize symbol indexes for ObjC names ever so
slightly. Additionally, I found that the variability in time also was
improved considerably.

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

Similarly to D150622 for private clause, the reduction is currently not
modeled in a good way. This patch is inspired by the reduction representation
in the omp dialect (D105358) and make a new representation for the reduction in
the OpenACC dialect.

A new operation is introduced to model the sequences of operation needed to
initialize a local reduction value and how to combine two values during the
reduction. The operation requires two mandatory regions.

  1. The init region specifies how to initialize the local reduction
     value. The region has an argument that contains the value of the
     reduction accumulator at the start of the reduction. It is expected to
     `acc.yield` the new value.
  2. The reduction region contains a sequences of operations to combine two
     values of the reduction type into one. It has two arguments and it is
     expected to `acc.yield` the combined value.

Example:

```mlir
acc.reduction.recipe @reduction_add_i64 : i64 init reduction_operator<add> {
^bb0(%0: i64):
  // init region contains a sequence of operations to initialize the local
  // reduction value as specified in 2.5.15
  %c0 = arith.constant 0 : i64
  acc.yield %c0 : i64
} reduction {
^bb0(%0: i64, %1: i64)
  // reduction region contains a sequence of operations to combine
  // two values into one.
  %2 = arith.addi %0, %1 : i64
  acc.yield %2 : i64
}

// The reduction symbol is then used in the corresponding operation.
acc.parallel reduction(@reduction_add_i64 -> %a : i64) {
}

Reviewed By: razvanlupusoru, vzakhari

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

This reverts commit 78d8d016.

Not sure what this was originally intended for, but this seems to be
unused. It didn't seem to be used when it was first added in D64630
either.

Reviewed By: jmorse

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

Some metadata prettyprinting, including variable prettyprinting and
debug line info comments, is currently only supported for `DBG_VALUE`.
This allows `DBG_INSTR_REF` can be printed in the same way.

Reviewed By: jmorse

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

When lowering ends up outlining the initialization of an entity
containing an array of c_ptr/c_funptr it is treating the array
initializer as scalar due to the missing check for the rank.
When initializing non-0 rank c_ptr/c_funptr entity it has to
recurse via genConstantValue().

Reviewed By: clementval

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

I must have copied these from SVE by accident. They aren't relevant
for RISC-V.

[libc++][NFC] Rename iterator category checks to make it obvious that they check //only// the iterator category

We plan to add concepts for checking that iterators actually provide what they claim to. This is to avoid people thinking that these type traits actually check the iterator requirements in more detail.

Reviewed By: ldionne, #libc

Spies: Mordante, libcxx-commits, wenlei

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

The padded sizes should be derived from destination tensor, not source
tensor. There could be more than one incomplete tile in padding domain.

Reviewed By: qedawkins

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

This will allow eliminating the intrinsic uses in the device
libraries, which will remove a subtarget dependency on the f16
version of the intrinsic.

We previously had some wrong patterns for this under unsafe math
which I've removed.

Do it in IR partially to take advantage of the much better isKnownNeverNaN
handling, and partially out of laziness to avoid repeating this in the DAG
and GlobalISel path. Plus I think this should be done much earlier. Ideally
this would be in InstCombine, but you can't introduce target intrinsics
from a generic instruction rooted pattern.

LLDB should guarantee that the strings returned by SBAPI methods
live forever. I went through every method that returns a string and made
sure that it was added to the ConstString StringPool before returning if
it wasn't obvious that it was already doing so.
I've also updated the docs to document this behavior.

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

Reviewed By: dcaballe, awarzynski

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

This is a followup to D150330, split out because it's not purely mechanical.

Depends On D150330

Reviewed By: aartbik

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

The goal of this patch is to make it easier to reason about the state of
ObjCLanguage::MethodName. I do that in several ways:
- Instead of using the constructor directly, you go through a factory
  method. It returns a std::optional<MethodName> so either you got an
  ObjCLanguage::MethodName or you didn't. No more checking if it's valid
  to know if you can use it or not.
- ObjCLanguage::MethodName is now immutable. You cannot change its
  internals once it is created.
- ObjCLanguage::MethodName::GetFullNameWithoutCategory previously had a
  parameter that let you get back an empty string if the method had no
  category. Every caller of this method was enabling this behavior so I
  dropped the parameter and made it the default behavior.
- No longer store all the various components of the method name as
  ConstStrings. The relevant `Get` methods now return llvm::StringRefs
  backed by the MethodName's internal storage. The lifetime of these
  StringRefs are tied to the MethodName itself, so if you need to
  persist these you need to create copies.

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

Both LLVM and LLDB implement DWARFAbbreviationDeclaration. As of
631ff46c, llvm's implementation of
DWARFAbbreviationDeclaration::extract behaves the same as LLDB's
implementation, making it easier to merge the implementations.

The only major difference between LLDB's implementation and LLVM's
implementation is that LLVM's DWARFAbbreviationDeclaration is slightly
larger. Specifically, it has some metadata that keeps track of the size
of a declaration (if it has a fixed size) so that it can potentially
optimize extraction in some scenarios. I think this increase in size
should be acceptable and possibly useful on the LLDB side.

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

The compiler emits a bogus 'No explicit type declared for...' error
when a dummy procedure turns out to be a subroutine (or at least not
a function or object) under control of IMPLICIT NONE.

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

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

@asbirlea reports that Google does this for sanitizer analysis
downstream. Looks like a few #defines are added into a header which is
then injected into the build.

Reviewed By: vitalybuka, ldionne, #libc_abi

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

The old code, which has regressed over many cleanups, has been replaced
with the new wide integer to hex string facility.

Reviewed By: michaelrj

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

Reviewed By: aartbik

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