This change simply avoids the temporary vector and processes the elments
right away.

- Add missing _LIBCPP_HIDE_FROM_ABI
- Implement inline functions in the class to simplify the code
- Add missing `const` to `operator()`
- Move _LIBCPP_DISABLE_UBSAN_UNSIGNED_INTEGER_CHECK to the usual location for function attributes

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

**Summary**

This patch addresses the case where we have a `DW_AT_external`
subprogram for a constructor (and/or destructor) that doesn't carry
a `DW_AT_linkage_name` attribute. The corresponding DIE(s) that
represent the definition will have a linkage name, but if the name
contains constructs that LLDBs fallback mechanism for guessing mangled
names to resolve external symbols doesn't support (e.g., abi-tags)
then we end up failing to resolve the function call.

We address this by trying to find the linkage name before we create
the constructor/destructor decl, which will get attached using
an `AsmLabelAttr` to make symbol resolution easier.

**Testing**

* Added API test

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

This relands the commit previously reverted in
`8570bee5` due to failures on linux.

The problem was that the test executable was built with absolute
OSO prefix paths. This re-commit adds a modified version of the
executable that strips the absolute OSO prefix paths and makes
sure the test appends the OSO prefix appropriately (via the appropriate
dsymutil flags).

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

The current code incorrectly returned the first instead of the last row.
This fixes the debug output.

Some conversions were still happening under no-complex/character-conversion
options. This change fixes that and adds a LIT test.

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

The current OpenMP implementation assumes the use of typed pointers (or rather typed pointer like types). Given the support for typed pointers in LLVM is now pending removal, the OpenMP Dialect should be able to support opaque pointers as well, given that any users of it must lower OpenMP through the LLVM Dialect.

This patch fixes the above and adds support for using LLVM opaque pointers with the OpenMP dialect. This is implemented by making all related code not make use of the element type of pointer arguments. The few (one) op requiring a pointer element type now use an explicit `TypeAttr` for representing the element type.
More concretely, the list of changes are:
* `omp.atomic.read` now has an extra `TypeAttr` (also in syntax) which is the element type of the values read and stored from the operands
* `omp.reduction` now has an type argument in the syntax for both the accmulator and operand since the operand type can no longer be inferred from the accumulator
* `OpenMPToLLVMIRTranslation.cpp` was rewritten to never query element types of pointers
* Adjusted the verifier to be able to handle pointers without element types

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

Part of https://discourse.llvm.org/t/rfc-switching-the-llvm-dialect-and-dialect-lowerings-to-opaque-pointers/68179

This patch adds the pass option 'use-opaque-pointers' to allow the dialect conversion from async to LLVM to create LLVM opaque pointers instead of typed pointers.
The gist of the changes boil down to having to propagate the choice of whether opaque or typed pointers should be used, to various helper functions that then either create typed pointers or opaque pointers.
This sadly creates a bit of a code duplication in comparison to other patches in this series, which I think is mostly unavoidable however, since a lot of the patterns in this lowering require the use of the AsyncTypeConverter, instead of the LLVMTypeConverter.

Besides that, the tests have been converter to opaque pointers with one file with typed pointer support having been created as regression tests.

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

Remove failure conditions for categories in libclang and return empty
content instead.

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

The current checks show incorrect debug output.

This function returns whether a block is nested inside of a loop. There
can be three kinds of loop:
  1) The block is nested inside of a LoopLikeOpInterface
  2) The block is nested inside another block which is in a loop
  3) There is a cycle in the control flow graph

This will be useful for Flang's stack arrays pass, which moves array
allocations from the heap to the stack. Special handling is needed when
allocations occur inside of loops to ensure additional stack space is
not allocated on each loop iteration.

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

As shown in issue #60649, the new shuffles were
being inserted before a phi, and that is invalid.

It seems like most test coverage for this fold
(foldSelectShuffle) lives in the AArch64 dir,
but this doesn't repro there for a base target.

When looking for defined symbols, look for symbols that aren't of a
type that we don't want, instead of having specific list of symbol
types that we do want. This fixes a problem where (when using GNU
nm at least) there were some symbol types that we want to export but
which weren't in the list.

The parameter in question belongs to a function that is only called once. This patch updates the API to use a reference and changes the caller accordingly.

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

This reverts commit dc4c3cfd.

Reverting because D143624 has been reverted.

Tail markings are not propagated if the transform succeeds.

This seems to cause large regressions in existing code, as much as 75% slower
(4x the time taken). Small always inline functions seem to be used a lot in the
cmsis-dsp library.

I would add a phase ordering test to show the problems, but one already exists!
The llvm/test/Transforms/PhaseOrdering/ARM/arm_mult_q15.ll was just changed by
removing alwaysinline to hide the problems that existed.

This reverts commit cae033dc.
This reverts commit 8e33c41e.

Reviewed By: scott.linder

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

This fixes a few places where the addrx3 and strx3 forms were missed.
Previously this meant if one of these forms appeared somewhere various
errors could occur. This now also adds an extra test case for the addrx3
form (which previously failed).

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

The refactoring !!Move function body to out-of-line!! produces incorrect code for methods of unnamed classes.
For this simple example
  // foo.h
  struct Foo {
    struct {
      void f^oo() {}
    } Bar;
  };

the refactoring generates code:
  // foo.cpp
  void Foo::(unnamed struct at D:\test\foo.h:2:3)foo() {}

Outplace definition for methods of unnamed classes is meaningless. The patch disables it.

Reviewed By: kadircet

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

The revision introduces operation attributes to store tbaa metadata on
load and store operations rather than relying using dialect attributes.
At the same time, the change also ensures the provided getters and
setters instead are used instead of a string based lookup. The latter
is done for the tbaa, access groups, and alias scope attributes.

The goal of this change is to ensure the metadata attributes are only
placed on operations that have the corresponding operation attributes.
This is imported since only these operations later on translate these
attributes to LLVM IR. Dialect attributes placed on other operations
are lost during the translation.

Reviewed By: vzakhari, Dinistro

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

The function clang_target_link_libraries must only be used with real
Clang libraries; with CLANG_LINK_CLANG_DYLIB, it will instead link in
clang-cpp. We must use the standard CMake target_link_libraries for
the HSA library.

```
void foobar(int);
int main() {
  foobar(1 + 2);
           ^
}
```

Currently the CalleeArgInfo will be "Passed by reference", which should
be "Passed by value".

Fixes https://github.com/clangd/clangd/issues/1467

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

This also requires us to constant fold vXi1 concat_vector nodes

Let's make sure that we only accept boolean expressions when using likely/unlikely.

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

Without this patch `getDerefOffsetInBytes` incorrectly always returns
`std::nullopt` for expressions with fragments due to an off-by-one error with
fragment element indices.

Reviewed By: StephenTozer

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

This commit adds support for the "llvm.loop.isvectorized" metadata and
ensures that the unroll followups match llvm's naming.

Reviewed By: gysit

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

Adds a bash script that syncs llvm/llvm-project and llvm/llvm-project-release-prs.
This should run on pushes to any of the repositories release branches.

I will follow this up with a change to the github actions to run this
script.

This breaks out the sync script from: https://reviews.llvm.org/D133476
so we can keep them separate.

Reviewed By: kwk

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

clang-cl doesn't support -dumpmachine directly, so we need to
preface it with /clang: in order to get this probing function
to work.

This is needed in order to run cmake directly on the runtimes
directory.

Reviewed By: hans

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

As suggested by @asb [here](https://reviews.llvm.org/D143570#4112877), we need tests for `.attribute stack_align`. This patch simply verifies a stack alignment of 16 is emitted for any combination of currently supported base ISA and extensions.

Reviewed By: asb, kito-cheng

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

Similar to 62a0a1b9 -

We have pow math intrinsics in IR, but no ldexp intrinsics
to handle vector types.

A patch for that was proposed in D14327, but it was not completed.

Issue #60605

Similar to D110763.

We have exp2 math intrinsics in IR, but no ldexp intrinsics
to handle vector types.

A patch for that was proposed in D14327, but it was not completed.

Issue #60605