Buffered diagnostics need ENABLE_VIRTUAL_TERMINAL_PROCESSING after D87272.
Do it unconditionally like FileCheck.

This change adds fallback-style flag to clang-format-diff.py

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

Reviewed By: rsuderman

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

folds conversion between identical types (with tests)

Reviewed By: ThomasRaoux

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

This allows clobbering a few extra registers in the fixed ABI, and
avoids some workitem ID packing instructions.

Drop the legacy version in AMDGPUAnnotateKernelFeatures. This has the
side effect of now respecting the linkage, and not changing externally
visible functions.

Previously we assumed all callable functions did not need any
implicitly passed inputs, and added attributes to functions to
indicate when they were necessary. Requiring attributes for
correctness is pretty ugly, and it makes supporting indirect and
external calls more complicated.

This inverts the direction of the attributes, so an undecorated
function is assumed to need all implicit imputs. This enables
AMDGPUAttributor by default to mark when functions are proven to not
need a given input. This strips the equivalent functionality from the
legacy AMDGPUAnnotateKernelFeatures pass.

However, AMDGPUAnnotateKernelFeatures is not fully removed at this
point although it should be in the future. It is still necessary for
the two hacky amdgpu-calls and amdgpu-stack-objects attributes, which
would be better served by a trivial analysis on the IR during
selection. Additionally, AMDGPUAnnotateKernelFeatures still
redundantly handles the uniform-work-group-size attribute to be
removed in a future commit.

At this point when not using -amdgpu-fixed-function-abi, we are still
modifying the ABI based on these newly negated attributes. In the
future, this option will be removed and the locations for implicit
inputs will always be fixed. We will then use the new attributes to
avoid passing the values when unnecessary.

It's possible in some cases for the LHS to be a pointer where the RHS is not. This isn't directly possible for an icmp, but the analysis mixes up operands of different icmp expressions in some cases.

This does not include a test case as the smallest reduced case we've managed is extremely fragile and unlikely to test anything meaningful in the long term.

Also add an assertion to getNotSCEV() to make tracking down this sort of issue a bit easier in the future.

Fixes https://bugs.llvm.org/show_bug.cgi?id=51787 .

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

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

This bit of code is incredibly suspicious. It allows fully unknown (but potentially negative) steps, but not steps known to be negative. The comment about scev flag inference is worrying, but also not correct to my knowledge.

At best, this might be covering up some related miscompile. However, there's no test in tree for it, the review history doesn't include obvious motivation, and the C++ example doesn't appear to give wrong results when hand translated to IR. I think it's time to remove this and see what falls out.

During review, there were concerns raised about the correctness of the corresponding signed case.  This change was deliberately narrowed to the unsigned case which has been auditted and appears correct for negative values.  We need to get back to the known-negative signed case, but that'll be a future patch if nothing falls out from this one.

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

Reviewed By: michaelrj

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

This patch updates the PC-Relative load and store patterns to utilize the
refactored load/store implementation introduced in D93370.

PC-Relative implementation has been added to PPCISelLowering.cpp, and also the
patterns in PPCInstrPrefix.td have been updated and no longer require AddedComplexity.
All existing test cases pass with this update.

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

Add integration tests for dyld interposition: DYLD_LIBRARY_PATH and
DYLD_INSERT_LIBRARIES.

DYLD_INSERT_LIBRARIES is also relevant for TSan thread
finalization/destruction sequence in the presence of additional pthread
introspection hooks (libBacktraceRecording.dylib for Xcode 'Queue
Debugging' feature).

rdar://78739125

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

Reviewed By: ymandel

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

Soft deprecrate isNullValue/isAllOnesValue and update in tree
callers. This matches the changes to the APInt interface from
D109483.

Reviewed By: lattner

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

Summary:
AIX have 2 byte wchar in 32 bit mode and 4 byte wchar in 64 bit mode.
This patch add more missing short wchar handling under the existing _LIBCPP_SHORT_WCHAR macro.

Marked test case ctor_move.pass.cpp as XFAIL for 32-bit mode on AIX because UTF-8 constants used cannot be converted to 2-byte wchar (by xingxue).

Authored by: jasonliu

Reviewed by: ldionne, zibi, SeanP, libc++

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

If the constant is a constant expression, then getAggregateElement()
will return null. Guard against this before calling HasFn().

This test is very verbose and appears generated by a script.
Make it truly autogenerated for easy updates.
NFC

Reviewed By: arsenm

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

Change-Id: I1352b17b6d13ab9c5650dbe95ef0da97f71f1930

We should have CGP copy the splats into the same basic block as the
shift so that SelectionDAG can fold them.

In general, howManyLessThans doesn't really want to work with pointers
at all; the result is an integer, and the operands of the icmp are
effectively integers.  However, isLoopEntryGuardedByCond doesn't like
extra ptrtoint casts, so the arguments to isLoopEntryGuardedByCond need
to be computed without those casts.

Somehow, the values got mixed up with the recent howManyLessThans
improvements; fix the confused values, and add a better comment to
explain what's happening.

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

This PR adds missing AtomicRMWKind::min/max cases which we would like to use for min/max reduction loop vectorizations.

Reviewed By: aartbik

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

Don't print stderr to commandline when configuring compiler-rt for
darwin platforms. NFC.

Reviewed By: delcypher

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

For consistency with the other surrounding tests.

This constrains the Mov* and similar pseudo instruction to take
GPR64common register classes rather than GPR64. GPR64 includs XZR
which is invalid here, because this pseudo instructions expands
into an adrp/add pair sharing a destination register. XZR is invalid
on add and attempting to encode it will instead increment the stack
pointer causing crashes (downstream report at [1]). The test case
there reproduces on LLVM11, but I do not have a test case that
reaches this code path on main, since it is being masked by
improved dead code elimination introduced in D91513. Nevertheless,
this seems like a good thing to fix in case there are other cases
that dead code elimination doesn't clean up (e.g. if `optnone` is
used and the optimization is skipped).

I think it would be worth auditing uses of GPR64 in pseudo
instructions to see if there are any similar issues, but I do not
have a high enough view of the backend or knowledge of the
Aarch64 architecture to do this quickly.

[1] https://github.com/JuliaLang/julia/issues/39818

Reviewed By: t.p.northover

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

This allows handling i128 values and fixes
https://bugs.llvm.org/show_bug.cgi?id=51789.

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

[libc++][NFC] Remove remnants of _LIBCPP_HAS_NO_STDOUT, which should have been removed by 87dd5198

Sphinx was giving warning on unescaped special symbol *. It was
an issue on systems treating warning as error.

As reported on PR51796, the _mm256_loadu2_m128i in particular was inserting bitcasts and shuffles with different types making it trickier for some combines, and prevented the value tracker from identifying the shuffle sequences as a single insert_subvector style concat_vectors pattern.

This patch instead concatenate the 128-bit unaligned loads with _mm256_set_m128*, which was written to avoid the unnecessary bitcasts and only emits a single shuffle.

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

Also, include <type_traits> unconditionally. There really isn't much
of a benefit in skipping it when exceptions are disabled.

Followup to D109483

The original change to add the workaround is from 10 years ago and a lot has happened with msvc and cmake and llvm's usage of cmake since and we no longer need the workaround for any scenarios that I am aware of. Build more is now correctly configured for multi-configuration generators such as Visual Studio.

The workaround is, however, causing issues with some of the recent mlir tests as because of the workaround we cannot correctly determine whether assertions are enabled (see https://reviews.llvm.org/D105961).

The original change is:

```
commit b46fdac4
Author: Andrew Trick <atrick@apple.com>
Date:   Tue Jun 28 16:32:01 2011

    cmake: Our MSVC build does not support config-time build mode.

    llvm-svn: 134008
```

Reviewed By: mehdi_amini

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

Follow up to suggestions in D109103 via hans:
  I think UnreachableDefault (or UnreachableFallthrough) would be a
  better name now, since it doesn't just omit the range check, it also
  omits the last bit test.

Reviewed By: hans

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

This will simplify an upcoming diff.