Detects code where a temporary object is directly constructed by calling
a constructor or using an initializer list and immediately assigned to a
reference variable.

Reviewed By: xgupta

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

Using implicit CHECK prefix in one FileCheck invocation and explicit
CHECK-V83A in the other one seems to misguide to use CHECK: lines as
a common matching prefix at various places. Also note that

; CHECK, CHECK-V83A: ...

line only matches the "CHECK-V83A" prefix.

This commit explicitly splits the checks into common ones (CHECK) and
invocation-specific ones (COMPAT and V83A) and updates the assertions
with the update_llc_test_checks.py script.

Reviewed By: efriedma, MaskRay

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

Currently, m_Mul() style matchers also match constant expressions.
This is a regular source of assertion failures (usually by trying
to do a match and then cast to Instruction or BinaryOperator) and
infinite combine loops. At the same time, I don't think this provides
useful optimization capabilities (all of the tests affected here are
regression tests for crashes / infinite loops).

Long term, all of these constant expressions (apart from possibly
add/sub) are slated for removal per
https://discourse.llvm.org/t/rfc-remove-most-constant-expressions/63179
-- but doing those removals can itself expose new crashes and
infinite loops due to the current PatternMatch behavior.

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

The previous version was using llvm::reverse(CallExpr::arguments()),
which causes problems when clang is compiled with GCC.

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

This doesn't really do anything but should simplify updating these
APIs in the near future.

The RISC-V psABI [1] defines them similarly to AArch64.

[1] https://github.com/riscv-non-isa/riscv-elf-psabi-doc/blob/master/riscv-elf.adoc#mapping-symbol

Reviewed By: yota9, Amir

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

Earlier, in the sparse backward dataflow analysis, data from the results
of an op implementing `RegionBranchOpInterface` was considered to flow
into the operands of every op that did not implement the
`RegionBranchTerminatorOpInterface` but was return-like and present
in a region of the former. It was thus also expected that the number of
results of the former be equal to the number of operands in the latter.

This understanding of dataflow is incorrect and thus this expectation is
also not justified. This commit fixes this incorrect understanding.

This commit ensures that these return-like ops are handled just like the
ops implementing the `RegionBranchTerminatorOpInterface`, which means
that, if this op has a region `A` whose successors are regions `B`, `C`,
and `D`, then data flows from the arguments (successor inputs) of `B`,
`C`, and `D` to the corresponding successor operands of this op.

This fix is also propagated to liveness analysis that earlier relied on
this incorrect implementation of the sparse backward dataflow analysis
framework and corrects some incorrect assumptions made in it.

Also cleaned up some unnecessary comments from the test file.

Issue: https://github.com/llvm/llvm-project/issues/64139

.

Signed-off-by: Srishti Srivastava <srishtisrivastava.ai@gmail.com>

Reviewed By: jcai19, matthiaskramm, Mogball

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

Instead of hacking around RVInst4, we can use RVInstIUnary to fill
in all 12 bits of the immediate.

Their exit code is otherwise dependent on whether /usr/local/cuda exists or the default target triple.

Otherwise %clang may fail if the default target triple isn't x86.

This reverts commit e39bf32b.

Some tests have different behaviors depent on whether certain directories/files are present on the host.
An incomplete list from https://lab.llvm.org/buildbot/#/builders/109/builds/70149

csky-toolchain.c
riscv*-toolchain.c
fuchsia.*
hip-*
ohos.c

Zb and Zk extensions both have some unary instructions where all
12 bits are fixed. Add a base format that allows this.

This switches the Zb instruction InstrFormatR to I, but that seems
more correct.

They may be either 0 or 1, depending whether `--target=` specifies a
native target.

Their exit code is otherwise dependent on whether /usr/local/cuda exists.

The exit code for -### is inconsistent. Unrecognized options lead to
exit code 1, as expected. However, most others errors (including invalid
option value) lead to exit code 0, differing from GCC and most utilities.

This is a longstanding quirk of -###, and we didn't fix it because many
driver tests need adjustment.

Change -### to be similar to -fdriver-only -v and exit with code 1.

This requires fixing many driver tests, but the end result gives us
stronger tests.

* Existing `RUN: %clang -### ...` tests usually don't use `CHECK-NOT: error:` or `--implicit-check-not=error:`.
  If a change introduces an error, such a change usually cannot be detected.
* Many folks contributing new tests don't know `-fdriver-only -v`.
  To test no driver error/warning for new tests, they can use the familiar `-### -Werror`
  instead of `-fdriver-only -v -Werror`.

Reviewed By: jhuber6, yaxunl, dblaikie

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

An upcoming change D156363 will change -### to exit with code 1 if
hasErrorOccurred. Some AMDGPU tests would exit with code 1 due to not
found CUDA installation.

The current implementation generates a csect with a
".rodata.str.x.y" prefix for a MergeableCString variable definition.
However, a reference to such variable does not get the prefix in its
name because there's not enough information in the containing IR.
In particular, without seeing the initializer and absent of some other
indicators, we cannot tell that the referenced variable is a null-
terminated string.

When the AIX codegen in llvm was being developed, the prefixing was copied
from ELF without having the linker take advantage of the info.
Currently, the AIX linker does not have the capability to merge
MergeableCString variables. If such feature would ever get implemented,
the contract between the linker and compiler would have to be reconsidered.

Here's the before and after of this change:
```
@a = global i64 320255973571806, align 8
@strA = unnamed_addr constant [7 x i8] c"hello\0A\00", align 1  ;; Mergeable1ByteCString
@strB = unnamed_addr constant [8 x i8] c"Blahah\0A\00", align 1 ;; Mergeable1ByteCString
@strC = unnamed_addr constant [2 x i16] [i16 1, i16 0], align 2 ;; Mergeable2ByteCString
@strD = unnamed_addr constant [2 x i16] [i16 1, i16 1], align 2 ;; !isMergeableCString
@strE = external unnamed_addr constant [2 x i16], align 2

-fdata-sections:
  .text  extern        .rodata.str1.1strA        .text  extern        strA
    0    SD       RO                               0    SD       RO
  .text  extern        .rodata.str1.1strB        .text  extern        strB
    0    SD       RO                               0    SD       RO
  .text  extern        .rodata.str2.2strC  ===>  .text  extern        strC
    0    SD       RO                               0    SD       RO
  .text  extern        strD                      .text  extern        strD
    0    SD       RO                               0    SD       RO
  .data  extern        a                         .data  extern        a
    0    SD       RW                               0    SD       RW
  undef  extern        strE                      undef  extern        strE
    0    ER       UA                               0    ER       UA

-fno-data-sections:
  .text  unamex        .rodata.str1.1            .text  unamex        .rodata
    0    SD       RO                               0    SD       RO
  .text  extern        strA                      .text  extern        strA
    0    LD       RO                               0    LD       RO
  .text  extern        strB                      .text  extern        strB
    0    LD       RO                               0    LD       RO
  .text  unamex        .rodata.str2.2      ===>  .text  extern        strC
    0    SD       RO                               0    LD       RO
  .text  extern        strC                      .text  extern        strD
    0    LD       RO                               0    LD       RO
  .text  unamex        .rodata                   .data  unamex        .data
    0    SD       RO                               0    SD       RW
  .text  extern        strD                      .data  extern        a
    0    LD       RO                               0    LD       RW
  .data  unamex        .data                     undef  extern        strE
    0    SD       RW                               0    ER       UA
  .data  extern        a
    0    LD       RW
  undef  extern        strE
    0    ER       UA
```

Reviewed by: David Tenty, Fangrui Song

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

An upcoming change D156363 will change -### to exit with code 1 if
hasErrorOccurred. Some AMDGPU tests would exit with code 0 due to not
found GPU installation.

[mlir] Add support for custom readProperties/writeProperties methods.

Currently, operations that opt-in to adopt properties will see auto-generated readProperties/writeProperties methods to emit and parse bytecode. If a dialects opts in to use `usePropertiesForAttributes`, those definitions will be generated for the current definition of the op without the possibility to handle attribute versioning.

The patch adds the capability for an operation to define its own read/write methods for the encoding of properties so that versioned operations can handle upgrading properties encodings.

In addition to this, the patch adds an example showing versioning on NamedProperties through the dialect version API exposed by the reader.

Reviewed By: mehdi_amini

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

Add support for parsing CTF forward declarations and converting them
into LLDB types.

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

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

This reverts commit 4166ff61. I accidentally
pushed an old version of this patch.

When I was trying to improve the OpenMP documentation, I found that the information in `OpenMP/docs/README.md` did not contain up-to-date information about how to build the OpenMP documentation with Sphinx. When I ran `make
docs-openmp-html`, the command failed because there were a few syntax errors in `openmp/docs/design/Runtimes.rst`. This commit fixes the syntax errors and updates the documentation on building the OpenMP documentation.

Reviewed By: jdoerfert

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

I have added a few things to the OpenMP FAQ which I think were missing. Feel free to suggest some changes. Are there missing options in the offloading command line reference? And what do you think about the section "Q: Why is my
build taking a long time"?

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

Added in a0d8a53c. Some fields are not always initialized.

The updated start indices weren't being used.

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

[mlir] Expose a mechanism to provide a callback for encoding types and attributes in MLIR bytecode.

Two callbacks are exposed, respectively, to the BytecodeWriterConfig and to the ParserConfig. At bytecode parsing/printing, clients have the ability to specify a callback to be used to optionally read/write the encoding. On failure, fallback path will execute the default parsers and printers for the dialect.

Testing shows how to leverage this functionality to support back-deployment and backward-compatibility usecases when roundtripping to bytecode a client dialect with type/attributes dependencies on upstream.

Reviewed By: rriddle

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

This reverts commit b299ec16.

The authorship informations were incorrect.

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

The other architectures use a brief sleep to defer work during this spin
loop that checks the RPC mailboxes. This patch adds one for x64 to
improve usage when running the server.

Reviewed By: tianshilei1992

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

The `allocsize` attribute is weird because it packs two 32-bit values
into a 64-bit value. It also turns out that the passthrough attribute
exporter was using `int`, which is incorrectly handling 64-bit integers.

Reviewed By: rriddle

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

There are some cases during member lookup we are aggressively suppressing
diagnostics when we should just be suppressing access control diagnostic.

In this PR I add the ability to simply suppress access diagnostics while not
suppressing ambiguous lookup diagnostics.

Fixes: https://github.com/llvm/llvm-project/issues/22413
https://github.com/llvm/llvm-project/issues/29942
https://github.com/llvm/llvm-project/issues/35574
https://github.com/llvm/llvm-project/issues/27224

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

The number of trailing zeroes was being calculated incorrectly. It was
assuming that it could add all of the implicit leading zeroes in the
final block, not accounting for the number of digits actually reqested
by the precision.

Reviewed By: lntue

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

This work introduces sm90 integration testing and adds a single test.

Depends on : D155825 D155680 D155563 D155453

Reviewed By: nicolasvasilache

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

On Apple platforms when debugging with libBacktraceRecording.dylib backtraces are stored as part of the thread stack. This change includes support for displaying the back traces when they are present in the stack trace.

To use this on macOS a binary needs to be run with the following environment variables configured:

DYLD_LIBRARY_PATH=/usr/lib/system/introspection
DYLD_INSERT_LIBRARIES=/Applications/Xcode.app/Contents/Developer/usr/lib/libBacktraceRecording.dylib
{F28473587}

Reviewed By: wallace

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

This respects the CMAKE_MSVC_RUNTIME_LIBRARY option for selecting
the right CRT to use.

Add a CI configuration that tests building this way.

Based on a patch by Andrew Ng.

The test config files end up accumulating and duplicating a fair
bit of cmake-specific logic here; if preferred, we could also add
that in `libcxx/test/CMakeLists.txt` and export a few more variables
to `cmake-bridge.cfg.in` instead.

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