This was used for LLVM_ALIGNAS() arguments in the past, but has
since been superseded by plain alignas() which also accepts a type.

The guidance since D94219 is to use [[deprecated]] directly. Now
that all historical uses of the macro have been removed, drop the
macro itself.

Remove the insertEdge(), insertEdgeRelaxed(), deleteEdge() and
deleteEdgeRelaxed() methods, which have been deprecated three
years ago.

This method has been deprecated for two years.

Update opencl-c.h after the specification clarification in
https://github.com/KhronosGroup/OpenCL-Docs/pull/775

There are no more in-tree users of this method, outside the
experimental SPIRV backend.

Rather than checking the bitcast pointer element types, compare
the element type of the access and the GEP result type.

The entire code is dubious due to the inspection of GEP structure,
but this at least preserves the spirit of the existing code.

Writes into tensors that are definied outside of a repetitive region, but with the write happening inside of the repetitive region were previously not considered conflicts. This was incorrect.

E.g.:
```
%0 = ... : tensor<?xf32>
scf.for ... {
  "reading_op"(%0) : tensor<?xf32>
  %1 = "writing_op"(%0) : tensor<?xf32> -> tensor<?xf32>
  ...
}
```

In the above example, "writing_op" should be out-of-place.

This commit fixes the bufferization for any op that declares its repetitive semantics via RegionBranchOpInterface.

`getFunction` was missing parentheses.

Reviewed By: ftynse, mehdi_amini

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

Reviewed By: jsji

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

This is a fix for previous typo. It makes no sense to return
PreservedAnalyses::all() if anything is change. This change simplify
codes further.

Re-run the update_cc_test_checks.py to update expected result.
I'm not sure why those tests are passed before.

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

Empty test commit, check commit access

The routine that facilitated symbols to be explicitly allowed asked
the name of the called function, which resulted in a crash when the
check was accidentally run on non-trivial C++ code.

Differential Revision: http://reviews.llvm.org/D123992

Reviewed By: aaron.ballman

Baseline tests for D123453(issue #54824)

A missing "!" in the call interface lowering caused all derived type
arguments without length parameters that require and explicit interface
to be passed via fir.box (runtime descriptor).

This was not the intent: there is no point passing a simple derived type
scalars or explicit shapes by descriptor just because they have an attribute
like TARGET. This would actually be problematic with existing code that is
not always 100% compliant: some code implicitly calls procedures with
TARGET dummy attributes (this is not something a compiler can enforce
if the call and procedure definition are not in the same file).

Add a Scope::IsDerivedTypeWithLengthParameter to avoid passing derived
types with only kind parameters by descriptor. There is no point, the
callee knows about the kind parameter values.

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

Fixes [[ https://github.com/llvm/llvm-project/issues/38995 | #38995 ]]

This is an attempt to modify the regular expression to identify
`@import` and `import` alongside the regular `#include`. The challenging
part was not to support `@` in addition to `#` but how to handle
everything that comes after the `include|import` keywords. Previously
everything that wasn't `"` or `<` was consumed. But as you can see in
this example from the issue #38995, there is no `"` or `<` following the
keyword:

```
@import Foundation;
```

I experimented with a lot of fancy and useful expressions in [this
online regex tool](https://regex101.com) only to find out that some
things are simply not supported by the regex implementation in LLVM.

 * For example the beginning `[\t\ ]*` should be replacable by the
   horizontal whitespace character `\h*` but this will break the
   `SortIncludesTest.LeadingWhitespace` test.

That's why I've chosen to come back to the basic building blocks.

The essential change in this patch is the change from this regular
expression:

```
^[\t\ ]*#[\t\ ]*(import|include)[^"<]*(["<][^">]*[">])
        ~                              ~~~~~~~~~~~~~~
        ^                              ^
        |                              |
        only support # prefix not @    |
                                       only support "" and <> as
delimiters
                                       no support for C++ modules and ;
                                       ending. Also this allows for ">
                                       or <" or "" or <> which all seems
                                       either off or wrong.
```

to this:

```
^[\t\ ]*[@#][\t\ ]*(import|include)([^"]*("[^"]+")|[^<]*(<[^>]+>)|[\t\
]*([^;]+;))
        ~~~~                        ~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~
~~~~~~~~~~~~~~
        ^                                 ^           ^       ^       ^
        |                                 |           |       |       |
        Now support @ and #.            Clearly support "" and <> as
well as an
                                        include name without enclosing
characters.
                                        Allows for no mixture of "> or
<" or
                                        empty include names.

```

Here is how I've tested this patch:

```
ninja clang-Format
ninja FormatTests
./tools/clang/unittests/Format/FormatTests
--gtest_filter=SortIncludesTest*
```

And if that worked I doubled checked that nothing else broke by running
all format checks:

```
./tools/clang/unittests/Format/FormatTests
```

One side effect of this change is it should partially support
[C++20 Module](https://en.cppreference.com/w/cpp/language/modules)
`import` lines without the optional `export` in front. Adding
this can be a change on its own that shouldn't be too hard. I say
partially because the `@` or `#` are currently *NOT* optional in the
regular expression.

I see an opportunity to optimized the matching to exclude `@include` for
example. But eventually these should be caught by the compiler, so...

With my change, the matching group is not at a fixed position any
longer. I decided to
choose the last match (group) that is not empty.

Reviewed By: HazardyKnusperkeks

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

The original patch leads to malformed phis on this test. Make sure
we're safeguarded from its return until it is fixed.

Make tests slightly more flexible for platforms which emit arguments in between some of the expected arguments.

test/Transforms/InstCombine/pr39177.ll failed in a -DLLVM_USE_SANITIZER=Undefined build.
```
lib/Transforms/Utils/BuildLibCalls.cpp:1217:17: runtime error: reference binding to null pointer of type 'llvm::Function'
```
`Function &F = *M->getFunction(Name);`

This reverts commit 0f8c6267.

Tests now try to run it, so we need a build file for it.

When a macro is undef'ed or used in a preprocessor conditional
expression, we need to remember that macro should it later be
defined in the file to an integral value.  We need to exclude
such macro names from being turned into an enum.

Maintain a blacklist of identifiers that we've seen in an
undef or conditional preprocessor directive.  When the file is
done processing, remove all the blacklisted identifiers from
conversion to an enum.

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

Fixes #54842

This patch adds check of supported reduction kind for ScanOp to avoid using and/or/xor for floating point type.

Reviewed By: ftynse

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

Many of the users of this add their own "error:" to the start,
resulting in error: error.

This is needed to use clang-include-fixer.

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

These don't seem to be very well used or tested, but try to make the
behavior a bit more consistent with LDS globals.

I'm not sure what the definition for amdgpu-gds-size is supposed to
mean. For now I assumed it's allocating a static size at the beginning
of the allocation, and any known globals are allocated after it.