This makes editing the table easier and mistakes more obvious.

Support ANSI escape codes for bright colors variants. Most modern
terminals support them. LLDB is not using them in any of its defaults,
but they're useful for people who want to modify their preferred ANSI
prefix/suffix.

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

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

When dealing with multiple phis that depend on each other, the order
might have been changed and may not match the expectation. If that
happens, bail out, rather than asserting.

Fixes https://github.com/llvm/llvm-project/issues/54218
Fixes https://github.com/llvm/llvm-project/issues/54233
Fixes https://github.com/llvm/llvm-project/issues/54254

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

This improves this test a lot because before when using the "attachCommands" to run the following commands:

(lldb) target create -d /path/to/a.out
(lldb) process launch

This was racy as it wasn't stopping the program at the entry point, and the process might run to completion before we can even debug it. With the recent changes to the "attachCommands" we were waiting for the process to stop, but the process might be exited already, and that _should_ have caused the attach to fail since there was no process to attach to. By adding "--stop-at-entry" to the process launch, we ensure this should be less racy and give us a valid process to attach to.

The loader TLS test for x86_64, which now passes, has been enabled.
A future change should enable the test for aarch64 as well.

Reviewed By: jeffbailey

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

When a contiguous range of a cooked character stream is being
mapped to a range of source provenance, the code was assuming
that the "end()" position of the input range -- being the character
immediately after the range -- would also follow the range's
source provenance.  This isn't always the case.

Modify the code to work with the true last character of the
input range (at end()-1) and to also cope with cases when that
last position truly maps to an earlier provenance, which can happen
when the prescanner has inserted a space into the cooked character
stream.

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

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

This ELF note is aarch64 and Android-specific. It specifies to the
dynamic loader that specific work should be scheduled to enable MTE
protection of stack and heap regions.

Current synthesis of the ".note.android.memtag" ELF note is done in the
Android build system. We'd like to move that to the compiler, and this
is the first step.

Reviewed By: MaskRay, jhenderson

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

vslide1up/down have this flag set, but the value isn't a splat.
Rename for clarity.

Reviewed By: khchen

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

Previously we used sra+add+xor if ADDCARRY is supported. This changes
to sra+xor+sub is SUBCARRY is available.

This is consistent with the recent change to the default expansion
in LegalizeDAG.

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

This method is redundant with the Operation* overload, and is an artifact of when
FuncOp wasn't an operation.

The current StandardToLLVM conversion patterns only really handle
the Func dialect. The pass itself adds patterns for Arithmetic/CFToLLVM, but
those should be/will be split out in a followup. This commit focuses solely
on being an NFC rename.

Aside from the directory change, the pattern and pass creation API have been renamed:
 * populateStdToLLVMFuncOpConversionPattern -> populateFuncToLLVMFuncOpConversionPattern
 * populateStdToLLVMConversionPatterns -> populateFuncToLLVMConversionPatterns
 * createLowerToLLVMPass -> createConvertFuncToLLVMPass

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

Add a utility function to strip comments from a "raw" tokenstream. The
derived stream will be fed to the GLR parser (for early testing).

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

Before this patch task priorities were ignored, that was a valid implementation
as the task priority is a hint according to OpenMP specification.

Implemented shared list of sorted (high -> low) task deques one per task
priority value. Tasks execution changed to first check if priority tasks ready
for execution exist, and these tasks executed before others;
otherwise usual tasks execution mechanics work.

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

AIX print -0.0 , inf, nan differently, which are causing the test
failures. We are OK for most other tests.

This patch remove the tests related these limitations conditionally on AIX,
so that we can enable the other tests to avoid losing test coverage.

The general direction is:

```
if strings don't differ between environments, keep the string literal "INF" and the padding, instead of folding them into variables.
```

Reviewed By: ldionne, #libc, Mordante

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

This was an oversight, as we did a avoild-nullable modication to
parameter-declaration-clause.

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

This patches adds the code to handle host association for
inner subroutines and functions.

This patch is part of the upstreaming effort from fir-dev branch.

Reviewed By: jeanPerier

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



Co-authored-by: Eric Schweitz <eschweitz@nvidia.com>
Co-authored-by: Jean Perier <jperier@nvidia.com>
Co-authored-by: V Donaldson <vdonaldson@nvidia.com>

This reverts commit 112135e7.
Breaks lld/test/MachO/{icf.s,cfstring-dedup.s,invalid/cfstring.s}

The index incrementation code used for FINDLOC, MAXLOC, and MINLOC folding
would crash if the array had a zero extent on the dimension selected with
a DIM= argument since the subscript passed to IncrementSubscripts would
have a value less than the lower bound.  Fix, and add tests.

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

This reverts commit 336e3677.
0c2b43ab was reverted in cf9b3ef9.

This reverts commit 0c2b43ab.

See
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92894#c3
https://reviews.llvm.org/D119589#inline-1151299

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

See also d96ae867.

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

Move `__quoted_output_proxy` into the one file that uses it.

A `const char*` has no associated traits class, so `std::quoted("literal")`
should be printable into any basic_ostream regardless of traits.

Use hidden-friend `operator<<` and `operator>>`, since we're permitted to.
(The exact signature is unspecified because the class itself is unspecified.)

We shouldn't support `std::quoted("literal")` in C++03 or C++11 mode.
(We do need `std::__quoted(s)` and `std::__quoted(cs)` in C++11 mode,
because they're used by `std::__fs::filesystem::path`.)

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

Fix a number of issues with MCSymbolizer::tryAddingSymbolicOperand()
in X86Disassembler:

  * Pass instruction size instead of immediate size.
  * Correctly adjust the value of PC-relative operands.
  * Set operand offset to zero when the operand is specified
    implicitly.

Reviewed By: Amir, skan

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

* Use default ref capture for non-escaping lambdas (this makes
  maintenance easier by allowing new uses, removing uses, having
  conditional uses (such as in assertions) not require updates to an
  explicit capture list)
* Simplify addPrivate API not to take a lambda, since it calls it
  unconditionally/immediately anyway - most callers are simply passing
  in a named value or short expression anyway and the lambda syntax just
  adds noise/overhead

Reviewed By: ABataev

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

The motivation is to enable the MSVC-style JMC instrumentation usable by a ELF-based
debugger. Since there is no prior experience implementing JMC feature for ELF-based
debugger, it might be better to just reuse existing MSVC-style JMC instrumentation.
For debuggers that support both ELF&COFF (like lldb), the JMC implementation might
be shared between ELF&COFF. If this is found to inadequate, it is pretty low-cost
switching to alternatives.

Implementation:
- The '-fjmc' is already a driver and cc1 flag. Wire it up for ELF in the driver.
- Refactor the JMC instrumentation pass a little bit.
- The ELF handling is different from MSVC in two places:
  * the flag section name is ".just.my.code" instead of ".msvcjmc"
  * the way default function is provided: MSVC uses /alternatename; ELF uses weak function.

Based on D118428.

Reviewed By: rnk

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

These unit tests resides in an internal repository. Porting the tests to the
public repository.

Reviewed By: aartbik

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

This reverts commit d8f4d546.

Merged by accident.

The default lowering of vector transpose operations generates a large sequence of
scalar extract/insert operations, one pair for each scalar element in the input tensor.
In other words, the vector transpose is scalarized. However, there are transpose
patterns where one or more adjacent high-order dimensions are not transposed (for
example, in the transpose pattern [1, 0, 2, 3], dimensions 2 and 3 are not transposed).
This patch improves the lowering of those cases by not scalarizing them and extracting/
inserting a full n-D vector, where 'n' is the number of adjacent high-order dimensions
not being transposed. By doing so, we prevent the scalarization of the code and generate a
more performant vector version.

Paradoxically, this patch shouldn't improve the performance of transpose operations if
we are using LLVM. The LLVM pipeline is able to optimize away some of the extract/insert
operations and the SLP vectorizer is converting the scalar operations back to its vector
form. However, scalarizing a vector version of the code in MLIR and relying on the SLP
vectorizer to reconstruct the vector code again is highly undesirable for several reasons.

Reviewed By: nicolasvasilache, ThomasRaoux

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

This is part of the implementation of the dataflow analysis framework.
See "[RFC] A dataflow analysis framework for Clang AST" on cfe-dev.

Reviewed-by: ymandel, xazax.hun

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

... from a `uint64_t` to a `uint32_t`. (LLD-ELF uses a `uint32_t` too.)

About a 1.7% reduction in peak RSS when linking chromium_framework on my
3.2 GHz 16-Core Intel Xeon W Mac Pro, and no stat sig change in wall
time.

           </Users/jezng/test2.sh ["before"]>  </Users/jezng/test2.sh ["after"]>  difference (95% CI)
  RSS      1003036672.000 ± 9891065.259        985539505.231 ± 10272748.749       [  -2.3% ..   -1.2%]
  samples  27                                  26

             base           diff           difference (95% CI)
  sys_time   1.277 ± 0.023  1.277 ± 0.024  [  -0.9% ..   +0.9%]
  user_time  6.682 ± 0.046  6.598 ± 0.043  [  -1.6% ..   -0.9%]
  wall_time  5.904 ± 0.062  5.895 ± 0.063  [  -0.7% ..   +0.4%]
  samples    46             28

No appreciable change (~0.01%) in number of `equals` comparisons either:

Before:

  ld64.lld: ICF needed 8 iterations
  ld64.lld: equalsConstant() called 701643 times
  ld64.lld: equalsVariable() called 3438526 times

After:

  ld64.lld: ICF needed 8 iterations
  ld64.lld: equalsConstant() called 701729 times
  ld64.lld: equalsVariable() called 3438526 times

Reviewed By: #lld-macho, MaskRay, thakis

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