Currently, if the user wants to inspect the raw version of a synthetic
variable, they have to go to the debug console and type `frame var
<variable>`, which is not a great experience. Taking inspiration from
CodeLLDB, this adds a `[raw]` child to every synthetic variable so that
this kind of inspection can be done visually.

Some examples:

<img width="500" alt="Screenshot 2023-09-06 at 7 56 25 PM"
src="https://github.com/llvm/llvm-project/assets/1613874/7fefb7c5-0da7-49c7-968b-78ac88348fea">
<img width="479" alt="Screenshot 2023-09-06 at 6 58 25 PM"
src="https://github.com/llvm/llvm-project/assets/1613874/6e650567-16e1-462f-9bf5-4a3a605cf6fc">

The formatter fails when num_children is invoked and self.impl_type is
not set.

Inspired by https://reviews.llvm.org/D120684#inline-1157644 and
subsequent LWG discussion. See http://wg21.link/LWG3207 for
additional context.

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



Co-authored-by: Louis Dionne <ldionne.2@gmail.com>

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



Co-authored-by: Louis Dionne <ldionne.2@gmail.com>

Fixes a corner case of the analysis: previously GlobalValues could be
affected by assumptions, but were not tracked within AffectedValues.
This patch allows assumptions which affect a given GlobalValue to be
looked up via `assumptionsFor()`.

A small update to llvm/test/Analysis/ScalarEvolution/ranges.ll was
necessary due to knowledge about a global value now being propagated
from AssumptionCache -> ValueTracking -> ScalarEvolution.

This happened because we had a section

```
- Index:           3
         Kind:            DATA
         Name:            weak_import_data
         Flags:           [ BINDING_WEAK, UNDEFINED ]
```

Which does not have size. We managed to reproduce it by building llvm
under msan with libcxx as a standard library and debug mode with
-D_LIBCPP_DEBUG_STRICT_WEAK_ORDERING_CHECK. It called comp(a, a) and
full tie detected uninitialized memory

This started to happen after https://reviews.llvm.org/D158799

This was only useful during the transition when mixing
non-opaque-pointer and opaque-pointer IR,
now everything uses opaque pointers.

We were invoking GetChildAtIndex(0) without checking the number of
children.
This was not crashing but was showing some warnings in python
formatters.

int a\
ス;

Failed to be parsed as a valid identifier.

Fixes #65156

Reviewed By: tahonermann

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

We've been displaying types and addresses for containers, but that's not
very useful information. A better approach is to compose the summary of
containers with the summary of a few of its children.

Not only that, we can dereference simple pointers and references to get
the summary of the pointer variable, which is also better than just
showing an anddress.

And in the rare case where the user wants to inspect the raw address,
they can always use the debug console for that.

For the record, this is very similar to what the CodeLLDB extension
does, and it seems to give a better experience.

An example of the new output:
<img width="494" alt="Screenshot 2023-09-06 at 2 24 27 PM"
src="https://github.com/llvm/llvm-project/assets/1613874/588659b8-421a-4865-8d67-ce4b6182c4f9">

And this is the 
<img width="476" alt="Screenshot 2023-09-06 at 2 46 30 PM"
src="https://github.com/llvm/llvm-project/assets/1613874/5768a52e-a773-449d-9aab-1b2fb2a98035">
old output:

On x86 targets, -fsplit-machine-functions enables splitting of machine
functions using profile information. This patch rolls out the flag for
AArch64 targets.

Depends on D158647

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

The OpenACC standard specifies an `atomic` construct in section 2.12 (of
3.3 spec), used to ensure that a specific location is accessed or
updated atomically. Four different clauses are allowed: `read`, `write`,
`update`, or `capture`. If no clause appears, it is as if `update` is
used.

The OpenMP specification defines the same clauses for `omp atomic`. The
types of expression and the clauses in the OpenACC spec match the OpenMP
spec exactly. The main difference is that the OpenMP specification is a
superset - it includes clauses for `hint` and `memory order`. It also
allows conditional expression statements. But otherwise, the expression
definition matches.

Thus, for OpenACC, we refactor and reuse the OpenMP implementation as
follows:
* The atomic operations are duplicated in OpenACC dialect. This is
preferable so that each language's semantics are precisely represented
even if specs have divergence.
* How...

NFC changes to explicitly specify the type we are matching when creating
Int32 reg. This will allow use to have multiple types mapping those
register without causing ambigous matching.

This code path doesn't exist anymore.

On AArch64, it is safe to let the linker handle relaxation of
unconditional branches; in most cases, the destination is within range,
and the linker doesn't need to do anything. If the linker does insert
fixup code, it clobbers the x16 inter-procedural register, so x16 must
be available across the branch before linking. If x16 isn't available,
but some other register is, we can relax the branch either by spilling
x16 OR using the free register for a manually-inserted indirect branch.

This patch builds on D145211. While that patch is for correctness, this
one is for performance of the common case. As noted in
https://reviews.llvm.org/D145211#4537173, we can trust the linker to
relax cross-section unconditional branches across which x16 is
available.

Programs that use machine function splitting care most about the
performance of hot code at the expense of the performance of cold code,
so we prioritize minimizing hot code size.

Here's a breakdown of the cases:

   Hot -> Cold [x16 is free across the branch]
     Do nothing; let the linker relax the branch.

   Cold -> Hot [x16 is free across the branch]
     Do nothing; let the linker relax the branch.

   Hot -> Cold [x16 used across the branch, but there is a free register]
     Spill x16; let the linker relax the branch.

     Spilling requires fewer instructions than manually inserting an
     indirect branch.

   Cold -> Hot [x16 used across the branch, but there is a free register]
     Manually insert an indirect branch.

     Spilling would require adding a restore block in the hot section.

   Hot -> Cold [No free regs]
     Spill x16; let the linker relax the branch.

   Cold -> Hot [No free regs]
     Spill x16 and put the restore block at the end of the hot function; let the linker relax the branch.
     Ex:
       [Hot section]
       func.hot:
         ... hot code...
       func.restore:
         ... restore x16 ...
         B func.hot

       [Cold section]
         func.cold:
         ... spill x16 ...
         B func.restore

     Putting the restore block at the end of the function instead of
     just before the destination increases the cost of executing the
     store, but it avoids putting cold code in the middle of hot code.
     Since the restore is very rarely taken, this is a worthwhile
     tradeoff.

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

Instead of hard-coding the name `lldbDataFormatters`, use `__name__` to
get the module's name.

This allows the formatters to be loaded from any path, with any
filename.

Based on https://en.cppreference.com/w/c/memory/aligned_alloc, the
`size` is supposed
to be a multiple of `alignment`, and it is implementation defined
behavior if not.
We have a non-conformant use in `kmp_barrier.h` when allocating
distribute barrier.
The size of the barrier is 576 and the alignment is `4*CACHE_LINE`,
which is 256
on most systems. Apparently it works perfectly fine for Linux and
Intel-based Mac,
but not for Apple Silicon based Mac.

Fix #63194.

This reverts commit ddbcc10b.

The 'clang-tidy/checkers/misc/header-include-cycle.cpp' test started failing on Windows: https://lab.llvm.org/buildbot/#/builders/216/builds/26855.

This reverts commit 11171d81.

Broke ASAN bot.

This addresses issues found by:
https://lab.llvm.org/buildbot/#/builders/92/builds/50285

Like concepts checking, a trailing return type of a lambda
in a dependent context may refer to captures in which case
they may need to be rebuilt, so the map of local decl
should include captures.

This patch reveal a pre-existing issue.
`this` is always recomputed by TreeTransform.

`*this` (like all captures) only become `const`
after the parameter list.

However, if try to recompute the value of `this` (in a parameter)
during template instantiation while determining the type of the call operator,
we will determine  it to be const (unless the lambda is mutable).

There is no good way to know at that point that we are in a parameter
or not, the easiest/best solution is to transform the type of this.

Note that doing so break a handful of HLSL tests.
So this is a prototype at this point.

Fixes #65067
Fixes #63675

Reviewed By: erichkeane

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

Adopt the new markup overload, introduced in 77d10325, in the MIPS
backend.

Summary:
A previous introduced a new object type for the GPU functions
implemented by an external vendor library. This was done so they we did
not attempt to run tests on functions which we did not implement,
however this accidentally stopped them from being included in the actual
output. Fix this by checking the new type as well.

The long term goal is to remove this vendor handling altogether, but is
being used as a short-term solution to provide a math library on the
GPU which currently lacks one.

We bumped the requirements to MSVC 2019 16.7 in 2022:
https://discourse.llvm.org/t/rfc-increasing-the-gcc-and-clang-requirements-to-support-c-17-in-llvm/59983
but missed updating these docs.

This commit partially reverts ddbcc10b to fix `clang-tools-extra/test/clang-tidy/infrastructure/clang-tidy-run-with-database.cpp`.

Added a class to hold such common state. The goal is to both reduce the argument list of other utilities used by `computeImportForModule` (which will be brought as members in a subsequent patch), and to make it easy to extend such state later.

This patch is part of a larger initiative aimed at fixing floating-point
`max` and `min` operations in MLIR:
https://discourse.llvm.org/t/rfc-fix-floating-point-max-and-min-operations-in-mlir/72671.

This patch addresses task 1.1 from the plan. It involves modifying the
lowering process for `arith.minf` and `arith.maxf` operations.
Specifically, the change replaces the usage of `llvm.minnum` and
`llvm.maxnum` with `llvm.minimum` and `llvm.maximum`, respectively. This
adjustment is necessary because the `m**num` intrinsics are not suitable
for the mentioned MLIR operations due to semantic discrepancies in
handling NaNs, positive and negative floating-point zeros.

The line continuations didn't have the proper spaces.

This is the first step to implement time zone support in libc++. This
adds the complete tzdb_list class and a minimal tzdb class. The tzdb
class only contains the version, which is used by reload_tzdb.

Next to these classes it contains documentation and build system support
needed for time zone support. The code depends on the IANA Time Zone
Database, which should be available on the platform used or provided by
the libc++ vendors.

The code is labeled as experimental since there will be ABI breaks
during development; the tzdb class needs to have the standard headers.

Implements parts of:
- P0355 Extending <chrono> to Calendars and Time Zones

Addresses:
- LWG3319 Properly reference specification of IANA time zone database

Reviewed By: #libc, ldionne

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

Summary:
The `omp_get_num_procs()` function should return the amount of
parallelism availible. On the GPU, this was not defined. We have elected
to define this function as the maximum amount of wavefronts / warps that
can be simultaneously resident on the device. For AMDGPU this is the
number of CUs multiplied byth CU's per wave. For NVPTX this is the
maximum threads per SM divided by the warp size and multiplied by the
number of SMs.

Previously, these tests expected that calling mktime with a struct tm
that caused overlow to succeed with return -1
(TimeConstants::OUT_OF_RANGE_RETURN_VALUE), however, the Succeeds call
expects the errno to be zero (no failure).

This patch fixes the expected calls to fail with EOVERFLOW. These tests
are only enabled to 32-bit systems, and are probably not being tested on
the arm32 buildbot, that's why this was not a problem before.

This test was setting tv_nsec to a negative value, which as per the
standard this is an EINVAL:

The value in the tv_nsec field was not in the range [0, 999999999] or
tv_sec was negative.

https://man7.org/linux/man-pages/man2/nanosleep.2.html

The calls were missing the __llvm_libc:: namespace, which can allow the
test case to be linked to glibc's clock_gettime.

Fixes `lldb/test/Shell/SymbolFile/NativePDB/inline_sites.test` to use the correct line number now that https://github.com/llvm/llvm-project/commit/f2f36c9b2955d2d742a198416f1178fd80303921 is causing the inline call site info to be taken into account.

This removes some uses of the deprecated `FileEntry::getName()`.