This is to avoid unnecessary traversals of the IR.

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

We should distribute ops that have other uses than the yield op as this
would duplicate those ops.

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

Our tiling implementation assumes a "tensor semantic" for the operation to
be tiled.
Prior to this patch, if we provide a tilable op with "buffer semantic", we
will assert instead of gracefully reject the input.

This patch turns the assert in a proper error.

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

The Opcode occupy 2 bytes in following test, we should use {{[0-9]+}}
to match the total value if it, not a part of it.
OPC_Decode(uleb128 Opcode, uleb128 DIdx)
and so do for OPC_TryDecode.

Check alias sets instead of traversing the IR.

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

- Add a convertProcedureDesignatorToHLFIR that converts the
  fir::ExtendedValue from the current lowering to a
  fir.boxproc/tuple<fir.boxproc, len> mlir::Value.

- Allow fir.boxproc/tuple<fir.boxproc, len> as hlfir::Entity values
  (a function is an address, but from a Fortran entity point of view,
  procedure that are not procedure pointers cannot be assigned to, so
  it makes a lot more sense to consider those as values).

- Modify symbol association to not generate an hlfir.declare for dummy
  procedures. They are not needed and allowing hlfir.declare to declare
  function values would make its verifier and handling overly complex
  for little benefits (maybe an hlfir.declare_proc could be added if it
  turnout out useful later for debug info and attributes storing
  purposes).

- Allow translation from hlfir::Entity to fir::ExtendedValue.
  convertToBox return type had to be relaxed because some intrinsics
  handles both object and procedure arguments and need to lower their
  object arguments "asBox". fir::BoxValue is not intended to carry
  dummy procedures (all its member functions would make little sense
  and its verifier does not accept such type).
  Note that AsAddr, AsValue and AsBox will always return the same MLIR
  value for procedure designators because they are always handled the
  same way in FIR.

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

Fixes https://github.com/llvm/llvm-project/issues/30923

Reviewed By: jacquesguan, aykevl

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

Implement scalbn via `fptuil::ldexp` for `FLT_RADIX==2` case.
"unimplemented" otherwise.

Reviewed By: lntue, sivachandra

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

Nested tuples were only supported in some narrow edge cases (and
potentially only because the test ops like `test.make_tuple` aren't
properly verified). This patch adds a couple of test cases with tested
tuple types and makes them work in the test pass by extending the
argument materialization and decomposition functions.

Reviewed By: silvas

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

This patch fixes:

  llvm/tools/llvm-c-test/debuginfo.c:211:12: error: unused variable
  'tag0' [-Werror,-Wunused-variable]

  llvm/tools/llvm-c-test/debuginfo.c:222:12: error: unused variable
  'tag1' [-Werror,-Wunused-variable]

Add support for the `--gdb-format`/`-G` flag to `dwim-print`.

The gdb-format flag allows users to alias `p` to `dwim-print`.

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

In lite mode, include split function fragments to the list of functions to
process even if a fragment has no samples. This is required to properly
detect and update split jump tables (jump tables that contain pointers to code
in the main and cold fragments).

Reviewed By: #bolt, maksfb

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

Reviewed By: nicolasvasilache

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

Test some more cases related to compare with 0 and inf.

[LoongArch] Add baseline tests for translating the selection of constants into mathematical operations

Fold class test performed by an fcmp into another class. For now this
avoids introducing new class calls then there isn't one that already
exists.

One of the tests in the commit
'bdf4f2be' sometimes fails on one of
the buildbots runing on a Windows machine. For example,
"https://lab.llvm.org/buildbot/#/builders/60/builds/10615" is a failed
build.

Now we disable it until we figure out why this could happen.

This patch squashes two tests with identical inputs into a single test, and adopts the `split-file` utility. This allows us to remove `sed` invocation with multiple commands, where "s|-E|-x objective-c -E|g" could've caused issues if previous replacements injected path containing "-E".

Reviewed By: benlangmuir

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

Making Select broadcastable can let this op easier to use.

Change-Id: I4a4bec4f7cbe532e954a5b4fe53136676ab4300c

Reviewed By: rsuderman

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

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

Add RISC-V and update Arm from (>= v6) to (>= v4).

Reviewed By: pirama

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

By switching them to external with default visibility, DSOs may not call
their own constructor/destructor. This is incorrect, because they pass
different parameters.

Fix it by marking the ctors/dtors as external linkage but with hidden
visibility.

Reviewed By: MaskRay

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

The th_task_state was initialized from the master thread's value, or
from its memo stack, but this causes problems because neither of those
may have the right value at the right time. However, other threads in
the team are guaranteed to have the right values, so we change the
initialize the new threads' th_task_state from the th_task_state of
the last of the older threads in the hot team.

Differential Revision: https://reviews.llvm.org/D142247
Fix #56307.

This patch adds a basic block profile dump option within the AsmPrinter
and dumps basic block profile information so that cost models can use
the data for downstream analysis.

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

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

Reviewed By: vitalybuka

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

Since we now only support Visual Studio 2019 16.7 and newer, we're able to use the `/Zc:preprocessor` flag that turns on the standards-conforming preprocessor. It (among other things) correctly expands `__VA_ARGS__` (see https://learn.microsoft.com/en-us/cpp/preprocessor/preprocessor-experimental-overview?view=msvc-170#macro-arguments-are-unpacked). This enables us to get rid of some repetitive boilerplate in Clang's command-line parser/generator.

Reviewed By: Bigcheese

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

(V == 0) ? 1 : V --> umax(V, 1)
(V == UMAX) ? UMAX-1 : V --> umin(V, UMAX-1)

https://alive2.llvm.org/ce/z/pfDBAf

This is one pair of the variants discussed in issue #60374.

Enhancements for the other end of the constant range and
signed variants are potential follow-ups, but that may
require more work because we canonicalize at least one
min/max like that to icmp+zext.

This commit adds a new option (i.e.,
`-fsanitize-cfi-icall-normalize-integers`) for normalizing integer types
as vendor extended types for cross-language LLVM CFI/KCFI support with
other languages that can't represent and encode C/C++ integer types.

Specifically, integer types are encoded as their defined representations
(e.g., 8-bit signed integer, 16-bit signed integer, 32-bit signed
integer, ...) for compatibility with languages that define
explicitly-sized integer types (e.g., i8, i16, i32, ..., in Rust).

``-fsanitize-cfi-icall-normalize-integers`` is compatible with
``-fsanitize-cfi-icall-generalize-pointers``.

This helps with providing cross-language CFI support with the Rust
compiler and is an alternative solution for the issue described and
alternatives proposed in the RFC
https://github.com/rust-lang/rfcs/pull/3296.

For more information about LLVM CFI/KCFI and cross-language LLVM
CFI/KCFI support for the Rust compiler, see the design document in the
tracking issue https://github.com/rust-lang/rust/issues/89653.

Relands b1e9ab74 with fixes.

Reviewed By: pcc, samitolvanen

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

When reseting modular options, propagate the values from certain options
that have ImpliedBy relations instead of setting to the default. Also,
verify in clang-scan-deps that the command line produced round trips
exactly.

Ideally we would automatically derive the set of options that need this
kind of propagation, but for now there aren't very many impacted.

rdar://105148590

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

D139603 (add option to llvm-profdata to reduce output profile size) contains test cases that are not cross-platform. Moving those tests to unit test and making sure the feature is callable from llvm library

Reviewed By: snehasish

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

Add a pair of clang pragmas:
- `#pragma clang unsafe_buffer_usage begin` and
- `#pragma clang unsafe_buffer_usage end`,
which specify the start and end of an (unsafe buffer checking) opt-out
region, respectively.

Behaviors of opt-out regions conform to the following rules:

- No nested nor overlapped opt-out regions are allowed. One cannot
  start an opt-out region with `... unsafe_buffer_usage begin` but never
  close it with `... unsafe_buffer_usage end`. Mis-use of the pragmas
  will be warned.
- Warnings raised from unsafe buffer operations inside such an opt-out
  region will always be suppressed. This behavior CANNOT be changed by
  `clang diagnostic` pragmas or command-line flags.
- Warnings raised from unsafe operations outside of such opt-out
  regions may be reported on declarations inside opt-out
  regions. These warnings are NOT suppressed.
- An un-suppressed unsafe operation warning may be attached with
  notes. These notes are NOT suppressed as well regardless of whether
  they are in opt-out regions.

The implementation maintains a separate sequence of location pairs
representing opt-out regions in `Preprocessor`.  The `UnsafeBufferUsage`
analyzer reads the region sequence to check if an unsafe operation is
in an opt-out region. If it is, discard the warning raised from the
operation immediately.

This is a re-land after I reverting it at 9aa00c8a.
The compilation error should be resolved.

Reviewed by: NoQ

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

Reviewed By: aartbik

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