This reverts commit 3c3faae4.

It breaks a number of bots.

This reverts commit 2cb926a4.

It depends on 3c3faae4, which is being
reverted.

This would stop on the first in reverse order, failing the verifier if
there were more earlier in the block.

[NFC][OpenMP] Renamed all variable and function names in `target` to conform with LLVM code standard

This patch only touched variables and functions in `target`.

Reviewed By: ye-luo

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

This needs an implicit def of the super-register in case one of the
lanes isn't defined, similar to copyPhysReg (or the not-VGPR spill
case below). This showed up in GlobalISel testing since it currently
doesn't fold out many undef instructions.

These should probably be inferred from the function on parse, but the
target specific infrastructure currently does not give you a way to do
this. SILowerSGPRSpills early exits without this reporting spills,
which makes it difficult to write a MIR test for.

Reviewed By: sammccall

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

This will fix the integration test which is failing currently.

Move `ResolveAccParts` and `ResolveOmpParts` from resolve-names.cpp to
resolve-directives.{h,cpp}. Move the implementation in the classes
`DirectiveAttributeVisitor`, `AccAttributeVisitor`, and
`OmpAttributeVisitor` to resolve-directives.cpp as well.

To allow this to happen, move `EvaluateIntExpr` and introduce
`EvaluateInt64` to resolve-names-utils.h. The latter is also useful
elsewhere in resolve-names.cpp for converting an Expr to std::int64_t.

The other problem was that `ResolveDesignator` was called from the code
that was moved. At the moment it doesn't seem to be doing anything so I
removed the calls (and no tests failed). If it proves to be needed, we
can either resolve those designators in resolve-names.cpp or pass the
`ResolveDesignator` function in to the code that needs to call it.

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

This class is currently used by two tools: HdrGen and PrototypeTestGen.
We will be adding more tools based on this class so it is convenient to
keep it in a util library of its own.

This adds the code to support calling mallopt and converting the
options to the internal Option enum.

Reviewed By: cryptoad

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

Reviewed By: sivachandra

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

Differential revision: https://reviews.llvm.org/D84800

Report captured variables in input dumps and traces.  For example:

```
$ cat check
CHECK: hello [[WHAT:[a-z]+]]
CHECK: goodbye [[WHAT]]

$ FileCheck -dump-input=always -vv check < input |& tail -8
<<<<<<
           1: hello world
check:1'0     ^~~~~~~~~~~
check:1'1           ^~~~~ captured var "WHAT"
           2: goodbye world
check:2'0     ^~~~~~~~~~~~~
check:2'1                   with "WHAT" equal to "world"
>>>>>>

$ FileCheck -dump-input=never -vv check < input
check2:1:8: remark: CHECK: expected string found in input
CHECK: hello [[WHAT:[a-z]+]]
       ^
<stdin>:1:1: note: found here
hello world
^~~~~~~~~~~
<stdin>:1:7: note: captured var "WHAT"
hello world
      ^~~~~
check2:2:8: remark: CHECK: expected string found in input
CHECK: goodbye [[WHAT]]
       ^
<stdin>:2:1: note: found here
goodbye world
^~~~~~~~~~~~~
<stdin>:2:1: note: with "WHAT" equal to "world"
goodbye world
^
```

Reviewed By: thopre

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

Substitutions are already reported in the diagnostics appearing before
the input dump in the case of failed directives, and they're reported
in traces (produced by `-vv -dump-input=never`) in the case of
successful directives.  However, those reports are not always
convenient to view while investigating the input dump, so this patch
adds the substitution report to the input dump too.  For example:

```
$ cat check
CHECK: hello [[WHAT:[a-z]+]]
CHECK: [[VERB]] [[WHAT]]

$ FileCheck -vv -DVERB=goodbye check < input |& tail -8
<<<<<<
           1: hello world
check:1       ^~~~~~~~~~~
           2: goodbye word
check:2'0     X~~~~~~~~~~~ error: no match found
check:2'1                  with "VERB" equal to "goodbye"
check:2'2                  with "WHAT" equal to "world"
>>>>>>
```

Without this patch, the location reported for a substitution for a
directive match is the directive's full match range.  This location is
misleading as it implies the substitution itself matches that range.
This patch changes the reported location to just the match range start
to suggest the substitution is known at the start of the match.  (As
in the above example, input dumps don't mark any range for
substitutions.  The location info in that case simply identifies the
right line for the annotation.)

Reviewed By: mehdi_amini, thopre

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

This patch implements OpenMP runtime support for the OpenMP TR8
`present` motion modifier for `omp target update` directives.  The
previous patch in this series implements Clang front end support.

Reviewed By: grokos

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

This patch implements Clang front end support for the OpenMP TR8
`present` motion modifier for `omp target update` directives.  The
next patch in this series implements OpenMP runtime support.

Reviewed By: ABataev

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

`to` and `from` clauses take the same modifiers, which are called
"motion modifiers" in TR8, so implement handling of their modifiers
once not twice.  This will make it easier to implement additional
motion modifiers in the future.

Reviewed By: ABataev

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

To avoid having this flag be passed in per/file manner, we are instead
passing it globally.

This fixes this bug: https://bugs.llvm.org/show_bug.cgi?id=46733

Reviewed-by: aaron.ballman, beanz, meinersbur

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

Only permit a placeholder type in a trailing-return-type if it would
also have been permitted in the decl-specifier sequence of a
corresponding declaration with no trailing-return-type. The standard
doesn't actually say this, but this is the only thing that makes sense.

Also fix handling of an 'auto' in a trailing-return-type in a parameter
of a generic lambda. We used to crash if we saw such a thing.

Summary:
Simplify ChildrenGetter to a simple wrapper around a GraphDiff call.
GraphDiff already handles nullptr in children, so the special casing in
clang can also be removed.

Reviewers: kuhar, dblaikie

Subscribers: llvm-commits, cfe-commits

Tags: #clang, #llvm

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

- Initiate the unit test with a test that tests variants of build() methods
  generated for ops with variadic operands and results.
- The intent is to migrate unit .td tests in mlir/test/mlir-tblgen that check for
  generated C++ code to these unit tests which test both that the generated code
  compiles and also is functionally correct.

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

Reviewed By: efriedma

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

Reviewed By: yln

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

Reviewed By: aditya_nandakumar

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

Fix not marking G_FENCE as legal on AMDGPU This was apparently
defaulting to legal using the "legacy" rules, whatever those are.

This allows sorting the legal/custom rules first as is recommended

 As requested in D79279.

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

We can't fold the masked compare value through the select if the
select condition is re-defed after the and instruction. Fixes a
verifier error and trying to use the outgoing value defined in the
block.

I'm not sure why this pass is bothering to handle physregs. It's
making this more complex and forces extra liveness computation.

As briefly discussed in IRC with @craig.topper,
the pass is disabled basically since it's original introduction (nov 2018)
due to  known correctness issues (miscompilations),
and there hasn't been much work done to fix that.

While i won't promise that i will "fix" the pass,
i have looked at it previously, and i'm sure i won't try to fix it
if that requires actually fixing this existing code.

Reviewed By: craig.topper

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

This reverts commit ab73b6da.

This reverts commit d054c7ee.

There are discussions about the utility name, its functionality and user interface.
Revert before we reach consensus.

types.

We previously did not treat a function type as dependent if it had a
parameter pack with a non-dependent type -- such a function type depends
on the arity of the pack so is dependent even though none of the
parameter types is dependent. In order to properly handle this, we now
treat pack expansion types as always being dependent types (depending on
at least the pack arity), and always canonically being pack expansion
types, even in the unusual case when the pattern is not a dependent
type. This does mean that we can have canonical types that are pack
expansions that contain no unexpanded packs, which is unfortunate but
not inaccurate.

We also previously did not treat a typedef type as
instantiation-dependent if its canonical type was not
instantiation-dependent. That's wrong because instantiation-dependence
is a property of the type sugar, not of the type; an
instantiation-dependent type can have a non-instantiation-dependent
canonical type.

Bug filled here: https://bugs.llvm.org/show_bug.cgi?id=45757.
Add comment to skipped regions so we don't track execution count for lines containing only comments.

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

Current implementation did not check that symbols is actually defined. Only checked for presence.  GNU ld documentation says,

"Return 1 if symbol is in the linker global symbol table and is defined before the statement using DEFINED in the script, otherwise return 0."

https://sourceware.org/binutils/docs/ld/Builtin-Functions.html#Builtin-Functions

Reviewed By: MaskRay

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