Record widening decisions for memory operations within the planned recipes and
use the recorded decisions in code-gen rather than querying the cost model.

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

Useful for OMP_TARGET_OFFLOAD=MANDATORY when testing

Reviewed By: Meinersbur

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

When folding A->B->C => A->C only accept A->C that is valid shape cast

Reviewed By: ThomasRaoux, nicolasvasilache

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

This reverts the following commits:
37ca7a79
9aa6c72b
705387c5
8ca4b3ef
80dba72a

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

The MIPS ABI requires the thread pointer be accessed via rdhwr $3, $r29.
This is currently represented by (CopyToReg $3, (RDHWR $29)) followed by
a (CopyFromReg $3). However, there is no glue between these, meaning
scheduling can break those apart. In particular, PR51691 is a report
where PseudoSELECT_I was moved to between the CopyToReg and CopyFromReg,
and since its expansion uses branches, it split the def and use of the
physical register between two basic blocks, resulting in the def being
eliminated and the use having no def. It also seems possible that a
similar situation could arise splitting up the CopyToReg from the RDHWR,
causing the RDHWR to use a destination register other than $3, violating
the ABI requirement.

Thus, add glue between all three nodes to ensure they aren't split up
during instruction selection. No regression test is added since any test
would be implictly relying on specific scheduling behaviour, so whilst
it might be testing that glue is preventing reordering today, changes to
scheduling behaviour could result in the test no longer being able to
catch a regression here, as the reordering might no longer happen for
other unrelated reasons.

Fixes PR51691.

Reviewed By: atanasyan, dim

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

Add a read-only `loc` property to Operation and OpView

Reviewed By: ftynse

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

Right now we only set a dependency on libc++ when the host is Darwin, which
means that libc++ in the build directory is in some undefined state when running
the test suite (it can be fully built, out-of-date or missing). Depending on
whether we have a system libc++ (which LLDB also supports running the libc++
tests against), the outcome is that we sometimes skip the libc++ tests or we run
the tests against a mix of ToT-libc++/system-libc++ (e.g., we compile against
the ToT-libc++ headers and link against the system libc++ library).

This can be demonstrated via `export LIT_FILTER=TestDataFormatterLibcxxSet ninja
check-lldb-api` (or any other libc++ test) and then gradually building parts of
libc++ in the same build (which will slowly change the test behaviour from
`UNSUPPORTED` to various failures to passing depending on how much of libcxx is
built at test time).

Note that this effectively re-enables the (unintentionally) disabled libc++
formatter tests on Linux. Don't revert this if it breaks a libc++ LLDB test,
instead please @skipIf decorate the failing test (as it was probably already
failing before this commit).

Reviewed By: labath

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

Accidentally committed a prior version of this patch. This is the
correct version.

The patterns added in D111441 should use the HasSVEorStreamingSVE
predicate. This changes one incorrect use of HasSVE with the new
patterns.

Try to widen element type to get a new mask value for a better permutation
sequence, so that we can use NEON shuffle instructions, such as zip1/2,
UZP1/2, TRN1/2, REV, INS, etc.
For example:
  shufflevector <4 x i32> %a, <4 x i32> %b, <4 x i32> <i32 6, i32 7, i32 2, i32 3>
is equivalent to:
  shufflevector <2 x i64> %a, <2 x i64> %b, <2 x i32> <i32 3, i32 1>
Finally, we can get:
  mov     v0.d[0], v1.d[1]

Reviewed By: dmgreen

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

It's been broken (not failing, but not testing anything either) for
quite some time now, and nobody noticed. It also (by design) tests
stepping through libc code, which makes it completely non-hermetic.

It's not worth reviving such a test.

This is NFC-intended for the callers. Posting in case there are
other potential users that I missed.
I would also use this from VectorCombine in a patch for:
https://llvm.org/PR52178 ( D111901 )

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

Fallback to stringification and string comparison if we cannot compare
the `IdentifierInfo`s, which is the case for C++ overloaded operators,
constructors, destructors, etc.

Examples:
  { "std", "basic_string", "basic_string", 2} // match the 2 param std::string constructor
  { "std", "basic_string", "~basic_string" }  // match the std::string destructor
  { "aaa", "bbb", "operator int" } // matches the struct bbb conversion operator to int

Reviewed By: martong

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

Refactor the code to make it more readable.

It will set up further changes, and improvements to this code in
subsequent patches.
This is a non-functional change.

Reviewed By: martong

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

This NFC change accomplishes three things:
1) Splits up the single unittest into reasonable segments.
2) Extends the test infra using a template to select the AST-node
   from which it is supposed to construct a `CallEvent`.
3) Adds a *lot* of different tests, documenting the current
   capabilities of the `CallDescription`. The corresponding tests are
   marked with `FIXME`s, where the current behavior should be different.

Both `CXXMemberCallExpr` and `CXXOperatorCallExpr` are derived from
`CallExpr`, so they are matched by using the default template parameter.
On the other hand, `CXXConstructExpr` is not derived from `CallExpr`.
In case we want to match for them, we need to pass the type explicitly
to the `CallDescriptionAction`.

About destructors:
They have no AST-node, but they are generated in the CFG machinery in
the analyzer. Thus, to be able to match against them, we would need to
construct a CFG and walk on that instead of simply walking the AST.

I'm also relaxing the `EXPECT`ation in the
`CallDescriptionConsumer::performTest()`, to check the `LookupResult`
only if we matched for the `CallDescription`.
This is necessary to allow tests in which we expect *no* matches at all.

Reviewed By: martong

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

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

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

__ompt_get_task_info_internal is now able to determine the right value of the
“thread_num” argument during the execution of an explicit task.

During the execution of a while loop that iterates over the ancestor tasks
hierarchy, the “prev_team” variable was always set to “team” variable at the
beginning of each loop iteration.

Assume that the program contains a parallel region which encloses an explicit
task executed by the worker thread of the region. Also assume that the tool
inquires the “thread_num” of a worker thread for the implicit task that
corresponds to the region (task at “ancestor_level == 1”) and expects to
receive the value of “thread_num > 0”.
After the loop finishes, both “team” and “prev_team” variables are equal and
point to the team information of the parallel region.
The “thread_num” is set to “prev_team->t.t_master_tid”, that is equal to
“team->t.t_master_tid”. In this case, “team->t.t_master_tid” is 0, since
the master thread of the region is the initial master thread of the program.
This leads to a contradiction.

To prevent this, “prev_team” variable is set to “team” variable only at the
time when the loop that has already encountered the implicit task (“taskdata”
variable contains the information about an implicit task) continues iterating
over the implicit task’s ancestors, if any.

After the mentioned loop finishes, the “prev_team” variable might be equal to
NULL. This means that the task at requested “ancestor_level” belongs to the
innermost parallel region, so the “thread_num” will be determined by calling
the “__kmp_get_tid”.

To prove that this patch works, the test case “explicit_task_thread_num.c” is
provided.
It contains the example of the program explained earlier in the summary.

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

Older intel compilers miss the privatization of nested loop variables for
doacross loops. Declaring the variable in the loop makes the test more
robust.

With Intel 19 compiler the teams tests fail to link while trying to link
liboffload.

As reported on https://pvs-studio.com/en/blog/posts/cpp/0771/ (Snippet 2) - (and mentioned on rGdc4259d5a38409) we are repeating the T1.isNull() check instead of checking T2.isNull() as well, and at this point neither should be null - so we're better off with an assertion.

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

Fixes an issue where GEP salvaging did not properly account for GEP
instructions which stepped over array elements of width 0 (effectively a
no-op). This unnecessarily produced long expressions by appending
`... + (x * 0)` and potentially extended the number of SSA values used
in the dbg.value. This also erroneously triggered an assert in the
salvage function that the element width would be strictly positive.
These issues are resolved by simply ignoring these useless operands.

Reviewed By: aprantl

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

Reviewed By: paulwalker-arm

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

When this code was added, an unnecessary assertion slipped in which we
now hit in real code.

Add a test to defend against it firing again.

With D110105, the isDebug flag for register uses is now a proxy for whether
the instruction is a debug instruction; that causes DBG_PHIs to have their
operands updated by calls to updateDbgUsersToReg, which is the correct
behaviour. However: that function only expects to receive DBG_VALUE
instructions and asserts such.

This patch splits the updating-action into a lambda, and applies it to the
appropriate operands for each kind of debug instruction. Tested with an
ARM test that stimulates this function: I've added some DBG_PHI
instructions that should be updated in the same way as DBG_VALUEs.

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

Refactor ConnectToRemote() to improve readability and make future
changes easier:

1. Replace static buffers with std::string.
2. When handling errors, prefer reporting the actual error over dumb
   'connection status is not success'.
3. Move host/port parsing directly into reverse_connection condition
   that is its only user, and simplify it to make its purpose (verifying
   that a valid port is provided) clear.
4. Use llvm::errs() and llvm::outs() instead of fprintf().

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

This reverts commit fa16329a.

See comments in discussion. Merged by mistake, not entirely getting what
the problem was.

This file was rewritten in rst format in clang/docs/Block-ABI-Apple.rst

clang format on some demangling files

Reviewed By: teemperor

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

When using explicit Clang modules, some declarations might unexpectedly become invisible.

This is caused by the mechanism that loads PCM files passed via `-fmodule-file=<path>` and creates an `IdentifierInfo` for the module name. The `IdentifierInfo` creation takes place when the `ASTReader` is in a weird state, with modules that are loaded but not yet set up properly. This patch delays the creation of `IdentifierInfo` until the `ASTReader` is done with reading the PCM.

Note that the `-fmodule-file=<name>=<path>` form of the argument doesn't suffer from this issue, since it doesn't create `IdentifierInfo` for the module name.

Reviewed By: dexonsmith

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

gcc11 warns that this counter causes a signed/unsigned comaprison when it's
later compared with a SmallVector::difference_type. gcc appears to be
correct, clang does not warn one way or the other.

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

TargetPassConfig::addPass takes a "bool verifyAfter" argument which lets
you skip machine verification after a particular pass. Unfortunately
this is used in generic code in TargetPassConfig itself to skip
verification after a generic pass, only because some previous target-
specific pass damaged the MIR on that specific target. This is bad
because problems in one target cause lack of verification for all
targets.

This patch replaces that mechanism with a new MachineFunction property
called "FailsVerification" which can be set by (usually target-specific)
passes that are known to introduce problems. Later passes can reset it
again if they are known to clean up the previous problems.

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