The 'counted_by' attribute is used on flexible array members. The
argument for the attribute is the name of the field member in the same
structure holding the count of elements in the flexible array. This
information can be used to improve the results of the array bound
sanitizer and the '__builtin_dynamic_object_size' builtin.

This example specifies the that the flexible array member 'array' has
the number of elements allocated for it in 'count':

  struct bar;
  struct foo {
    size_t count;
     /* ... */
    struct bar *array[] __attribute__((counted_by(count)));
  };

This establishes a relationship between 'array' and 'count',
specifically that 'p->array' must have *at least* 'p->count' number of
elements available. It's the user's responsibility to ensure that this
relationship is maintained through changes to the structure.

In the following, the allocated array erroneously has fewer elements
than what's specified by 'p->count'. This would result in an
out-of-bounds access not not being detected:

  struct foo *p;

  void foo_alloc(size_t count) {
    p = malloc(MAX(sizeof(struct foo),
                   offsetof(struct foo, array[0]) + count *
                       sizeof(struct bar *)));
    p->count = count + 42;
  }

The next example updates 'p->count', breaking the relationship
requirement that 'p->array' must have at least 'p->count' number of
elements available:

  struct foo *p;

  void foo_alloc(size_t count) {
    p = malloc(MAX(sizeof(struct foo),
                   offsetof(struct foo, array[0]) + count *
                       sizeof(struct bar *)));
    p->count = count + 42;
  }

  void use_foo(int index) {
    p->count += 42;
    p->array[index] = 0; /* The sanitizer cannot properly check this access */
  }

Reviewed By: nickdesaulniers, aaron.ballman

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

[mlir][Linalg]: Optimize linalg generic in transform::PromoteOp to avoid unnecessary copies (#68555)

If the operands are not used in the payload of linalg generic operations, there is no need to copy them before the operation.

This patch adds a `SBType::FindDirectNestedType(name)` function which performs a non-recursive search in given class for a type with specified name. The intent is to perform a fast search in debug info, so that it can be used in formatters, and let them remain responsive.

This is driven by my work on formatters for Clang and LLVM types. In particular, by [`PointerIntPairInfo::MaskAndShiftConstants`](https://github.com/llvm/llvm-project/blob/cde9f9df79805a0850310870d6dcc64004292727/llvm/include/llvm/ADT/PointerIntPair.h#L174C16-L174C16), which is required to extract pointer and integer from `PointerIntPair`.

Related Discourse thread: https://discourse.llvm.org/t/traversing-member-types-of-a-type/72452

Note that llvm::support::endianness has been renamed to
llvm::endianness while becoming an enum class. This patch replaces
{big,little,native} with llvm::endianness::{big,little,native}.

This patch completes the migration to llvm::endianness and
llvm::endianness::{big,little,native}.  I'll post a separate patch to
remove the migration helpers in llvm/Support/Endian.h:

  using endianness = llvm::endianness;
  constexpr llvm::endianness big = llvm::endianness::big;
  constexpr llvm::endianness little = llvm::endianness::little;
  constexpr llvm::endianness native = llvm::endianness::native;

hasOneUse can be more expensive for nodes with multiple outputs.
It's better to check the opcode first to skip nodes with multiple
outputs.

I have not seen an issue from this, just noticed while reviewing
code for a possible enhancement.

These source files do not use StringMap.h.

These source files do not use StringMap.h.

These source files do not use function_ref.

Update `LegalizerHelper::widenScalarMulo` to not create a mulo if we aren't going to use the overflow flag. This prevents needing to legalize the widened operation. This generates better code when we need to make a libcall for multiply.

These source files do not use StringMap.

Identified with misc-unused-using-decls.

`R_PPC64_GOT_TLSGD_PCREL34` is generated for pwr10+.

The last use of StringMap was removed by:

  commit 20157410
  Author: Vince Bridgers <vince.a.bridgers@gmail.com>
  Date:   Thu Jul 16 12:55:32 2020 -0500

This PR addresses a smaller detail discussed in the code review for
https://github.com/llvm/llvm-project/pull/66968. Currently, some
functions in the `libc++` PSTL CPU backend have been appended with a
digit to indicate the number of input iterator arguments. However, there
is no need to change the name for each version as overloading can be
used instead. This PR will make the naming more consistent in the the
CPU and the proposed OpenMP backend.

When narrowing logic ops(OR/XOR) with constant rhs, `DAGCombiner` will fixup the constant rhs node.
It is incorrect when lhs is also a constant. For example, we will incorrectly replace `xor OpaqueConstant:i64<8191>, Constant:i64<-1>` with `xor (and OpaqueConstant:i64<8191>, Constant:i64<65535>), Constant:i64<-1>`.

Fixes #68855.

I had trouble getting patterns working previously because GISel was
using an i32 immediate, but the instructions expected an i64 immediate
because SelectionDAG doesn't have i32 as a legal type yet.

After looking at other targets like AMDGPU, I discovered that I could
use a SDNodeXForm and a cast to get the type checking in tablegen to
allow me to do it.

https://lab.llvm.org/buildbot/#/builders/96/builds/46935 https://lab.llvm.org/buildbot/#/builders/68/builds/61651 are failing because of some namespace changes introduced by https://reviews.llvm.org/rG1673a1ba5dec

This commit adds the initial version of the mlir-query tool, which leverages the pre-existing matchers defined in mlir/include/mlir/IR/Matchers.h

The tool provides the following set of basic queries:

hasOpAttrName(string)
hasOpName(string)
isConstantOp()
isNegInfFloat()
isNegZeroFloat()
isNonZero()
isOne()
isOneFloat()
isPosInfFloat()
isPosZeroFloat()
isZero()
isZeroFloat()

Reviewed By: jpienaar

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

As a followup of https://github.com/llvm/llvm-project/pull/67851, I'm
defining a new namespace `lldb_plugin::dwarf` for the classes in this
Plugins/SymbolFile/DWARF folder. This change is very NFC and helped me
with exporting the necessary symbols for my out-of-tree language plugin.
The only class that I didn't change is ClangDWARFASTParser, because that
shouldn't be in the same namespace as the generic language-agnostic
dwarf parser.
It would be a good idea if other plugins follow the same namespace
scheme.

Implement __prefetch intrinsic. 

MSVC docs:
https://learn.microsoft.com/en-us/cpp/intrinsics/arm64-intrinsics?view=msvc-170

Bug: https://github.com/llvm/llvm-project/issues/65405

While running into failures on unmap calls, it becomes difficult to
figure out what's wrong. Break the dieOnMapUnmapError into specific
versions for map, unmap, and then one for mprotect.

Also, put these in a common linux space so that all linux derived code
can reuse this code.

This cherry-picks the changes in
llvm-project/5bf701a6 and extends the
pattern to handle vector types.

To reuse `getBoolAttribute` method, it moves the static method above the
include of generated file.

Split off from D158333.

To get the number of children for a VectorType (i.e.,
a type declared with a `vector_size`/`ext_vector_type` attribute)
LLDB previously did following calculation:
1. Get byte-size of the vector container from Clang (`getTypeInfo`).
2. Get byte-size of the element type we want to interpret the array as.
   (e.g., sometimes we want to interpret an `unsigned char vec[16]`
   as a `float32[]`).
3. `numChildren = containerSize / reinterpretedElementSize`

However, for step 1, clang will return us the *aligned* container
byte-size.
So for a type such as `float __attribute__((ext_vector_type(3)))`
(which is an array of 3 4-byte floats), clang will round up the
byte-width of the array to `16`.
(see
[here](https://github.com/llvm/llvm-project/blob/ab6a66dbec61654d0962f6abf6d6c5b776937584/clang/lib/AST/ASTContext.cpp#L1987-L1992))

This means that for vectors where the size isn't a power-of-2, LLDB
will miscalculate the number of elements.

**Solution**

This patch changes step 1 such that we calculate the container size
as `numElementsInSource * byteSizeOfElement`.

Annotating switch braces for the first time.

Also in preparation of #67906.

We support GCC 13, which supports the flag. This allows simplifying the
CMake logic around the use of -nostdlib++. Note that there are other
places where we don't assume -nostdlib++ yet in the build, but this
patch is intentionally trying to be small because this part of our CMake
is pretty tricky.

The other 3 sanitizers (ASAN, TSAN and MSAN) all use
maybeMarkSanitizerLibraryCallNoBuiltin to make disable optimizations
which inline functions like memcmp for example. The lack of this
optimization was allowing ExpandMemCmpPass to convert a memcmp call to
inlined assembly and cause a false negative in HWASAN.

The type formatter code is effectively considering empty strings as read
errors, which is wrong. The fix is very simple. We should rely on the
error object and stop checking the size. I also added a test.