This patch introduces the reduction intrinsic for floating point minimum
and maximum which has the same semantics (for NaN and signed zero) as
llvm.minimum and llvm.maximum.

Reviewed-By: nikic

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

Update to use new shufflevector semantics for undefined values in the mask

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

As pointed out in D141870, this one was incorrectly referencing and.

Macro was defined twice.

These tests check statistics results which require assertions enabled.

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

desugarForDiagnostic only sets value to true.

Tests are subset of llvm/unittests/ADT/ArrayRefTest.cpp.
Added more members to match tests and
make class more useful.

Reviewed By: hctim

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

Part of test coverage for Issue #62969

Fix two issues:

--hip-path should not do rigorous checking, i.e. if .hipVersion exists it
will use it, otherwise it will not error out but assumes the default
HIP version. This is to be consistent with --rocm-path behavior.

when HIP_PATH is empty, it should be ignored. This is to be consistent
with ROCM_PATH behavior.

Reviewed by: Artem Belevich

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

Fixes: SWDEV-404771

Reviewed By: #libc, ldionne, Mordante

Spies: Mordante, ldionne, libcxx-commits

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

Reviewed By: #libc, ldionne

Spies: ldionne, libcxx-commits

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

Currently `llvm/test/MC/RISCV/rv64zbb-valid.s` doesn't cover all
the instructions e.g. `maxu` and `llvm/test/MC/RISCV/rv32zbb-valid.s`
can have rv64 run lines, similar to what Zba instruction tests have.

This patch does the following.
- Add rv64 run lines in `llvm/test/MC/RISCV/rv32zbb-valid.s`
- Keep only rv64 specific instructions in `llvm/test/MC/RISCV/rv64zbb-valid.s`
- Move rv32 instructions, with different encodings from rv64, into
  `llvm/test/MC/RISCV/rv32zbb-only-valid.s`

Reviewed By: asb

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

TaskQueue was added several years ago as part of D48240.

There are currently no uses of this class anywhere in LLVM and I don't see
any patch that plans to use this class, so it doesn't seem useful to keep
compiling and testing this class at the moment.

The code itself is fine, so if we actually end up having a use for this code,
then I think it's perfectly fine to just re-commit this class then.

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

This was un-XFAILed in `83cb2123`
due to D144999. Since then D152540 fixed emission of eh_frame's
on Darwin, causing this test to fail again.

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

Add Int<> and Int128 types to replace the usage of __int128_t in math
functions.  Clean up to make sure that (U)Int128 and __(u)int128_t are
interchangeable in the code base.

Reviewed By: sivachandra, mikhail.ramalho

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

For example,

 smull(trunc(x), extract_high(y))
 ==>
 smull(extract_high(uzp1(undef,x)), extract_high(y))

 -> It will be matched to smull2

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

(This patch addresses the comment from https://reviews.llvm.org/D151785#4402460.)

Previously, we used a special printing policy that enabled `PrintCanonicalTypes`
to print type hints for structure bindings. This was intended to
eliminate type aliases like `tuple_element::type`. However, this also
caused TypePrinter to print default template arguments, which could
result in losing the ability to see types like `std::basic_string<char>`
if the fully expanded template-id exceeded the default inlay hint threshold.

Simply getting the canonical type at the call site could help us get rid of
the side effect.

This also merges overloaded `addTypeHint` into one function without
`PrintingPolicy`.

Reviewed By: nridge

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

When building the compiler with -DLLVM_ENABLE_EXPENSIVE_CHECKS=ON,
sometimes resources that are dumped in scheduled traces gets reordered
even if they are booked in the same cycle. Using `stable_sort`
guarantees that such occasional reordering does not happen.

This change should fix failures like the one seen in
https://lab.llvm.org/buildbot/#/builders/16/builds/49592.

Reviewed By: RKSimon

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

SPARC jmp requires a delay slot after, and without it will likely result
in a crash. For now, just disable interceptor trampolines on SPARC,
because the specific usecase for them (3 interceptors) does not exist on
SPARC (yet). We can revisit, and carefully implement the support for
SPARC when required.

Reported-by: ro

See https://discourse.llvm.org/t/rfc-enable-assignment-tracking/69399

This sets the -Xclang -fexperimental-assignment-tracking flag to the value
enabled which means it will be enabled so long as none of the following are
true: it's an LTO build, LLDB debugger tuning has been specified, or it's an O0
build (no work is done in any case if -g is not specified or -gmlt is used).

This reverts commit 9e7f14a8 which reverts
https://reviews.llvm.org/D146987

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

While BlockFrequency::operator+= is a very simple operation, it's
definition is present in another TU which means that it doesn't get
inlined in non-LTO builds. This means that there is some performance
left on the table in those builds, as this operator is called many
times.

This patch moves that operator (and a few others) into the
BlockFrequency.h header which gives a small speedup (~0.1%):
https://llvm-compile-time-tracker.com/compare.php?from=6ee594be53e7efaa12086ad20f0d0268092a4c73&to=6ac6cd99e211fae5ae5de41ad608604aa22f1882&stat=instructions%3Au

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

Split from D151795. I'm not sure it's conclusive, but these are all the related
tests I could find easily.

Reviewed By: MaskRay

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

This patch alleviates https://github.com/clangd/clangd/issues/1298.

Containers in C++ such as `std::vector` or `llvm::SmallVector`,
introduce a series of type aliases to adapt to generic algorithms.

Currently, If we write an declarator involving expressions with
these containers and `auto` placeholder, we probably obtain opaque
type alias like following:

```
std::vector<int> v = {1, 2, 3};
auto value = v[1]; // hint for `value`: value_type
auto *ptr = &v[0]; // hint for `ptr`: value_type *
```

These hints are useless for most of the time. It would be nice if we
desugar the type of `value_type` and print `int`, `int *` respectively
in this situation. But note we can't always prefer desugared type
since user might introduce type-aliases for brevity, where printing
sugared types makes more sense.

This patch introduces a heuristic method that displays the desugared
type that is an alias of template parameter. It merges
analogous method `shouldPrintCanonicalType` into `maybeDesugar` as well.

Previous commit for shouldPrintCanonicalType: dde8a0fe

Reviewed By: nridge

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

[X86] X86FixupVectorConstantsPass - attempt to replace full width fp vector constant loads with broadcasts on AVX+ targets (REAPPLIED)

lowerBuildVectorAsBroadcast will not broadcast splat constants in all cases, resulting in a lot of situations where a full width vector load that has failed to fold but is loading splat constant values could use a broadcast load instruction just as cheaply, and save constant pool space.

NOTE: SSE3 targets can use MOVDDUP but not all SSE era CPUs can perform this as cheaply as a vector load, we will need to add scheduler model checks if we want to pursue this.

This is an updated commit of 98061013 after being reverted at a279a09a

This broke cross-builds of llvm from x86_64 to arm64 mac, see
comment on
https://github.com/llvm/llvm-project/commit/1d6c3e29f6aa45914faa7be00a939b8f550f38e9

> so that they get an error on non-x86 targets.
> Follow-up to D151590.
>
> As a workaround for https://github.com/llvm/llvm-project/issues/63270, we don't
> report an error for -msse4.2.

This reverts commit 1d6c3e29.

/home/jiefu/llvm-project/llvm/lib/Target/X86/X86LegalizerInfo.cpp:48:1: error: unused function 'widen_1' [-Werror,-Wunused-function]
widen_1(const LegacyLegalizerInfo::SizeAndActionsVec &v) {
^
1 error generated.

Similar to the other patterns, this adds predicated and/xor/xor patterns.

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

Add missing include guards to LLVM header files that did not previously
have them and update existing include guards to ensure that they enclose
all non-whitespace, non-comment text to enable these headers for the
multiple-include optimization.

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

MachineConstantPool::getConstantPoolIndex - don't reuse mismatched constants contained undef/poison (Issue #63108)

This patch fixes an issue where we were reusing constant pool entries that contained undef elements, despite the additional uses of the 'equivalent constant' requiring some/all of the elements to be zero.

The CanShareConstantPoolEntry helper function uses ConstantFoldCastOperand to bitcast the type mismatching constants to integer representations to allow comparison, but unfortunately this treats undef elements as zero (which they will be written out as in the final asm). This caused an issue where the original constant pool entry contained undef elements, which was shared with a later constant that required the elements to be zero. This then caused a later analysis pass to incorrectly discard these undef elements.

Ideally we need a more thorough analysis/merging of the constant pool entries so the elements are forced to real zero elements, but for now we just prevent reuse of the constant pool entry entirely if the constants don't have matching undef/poison elements.

Fixes #63108

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

Replace the legacy legalizer versions - still WIP but matches existing features, plus handles legal vector types.