Add some atomic optimizer tests where there is no use of the result of
the atomic operation, which is a common case in real code. NFC.

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

It is possible that imported `SourceLocExpr` can cause not expected behavior (if `__builtin_LINE()` is used together with `__LINE__` for example) but still it may be worth to import these because some projects use it.

Reviewed By: teemperor

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

Installing the Unix tools on Windows is quite painful. To make things easier,
I explained how to use a package manager or a Docker image.

Note: This still uses the GNUWin tools as explained on this page. Once we
replace these with something else, we would also need to update the
installation commands.

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

This came out of my review comments on D97283.

This patch re-enables the use of `__is_fundamental`, `__is_signed`, etc.
on non-Clang compilers. Previously, when we found that a builtin didn't
work on old Clangs, we had been reacting by limiting its use to new Clangs
(i.e., we'd also stop using it on new GCCs and new MSVCs, just because of
the old Clang bug). I claim that this was unintentional.

Notice that on Apple Clang, `_LIBCPP_COMPILER_CLANG` is defined and
`_LIBCPP_CLANG_VER` is not defined (therefore `0` in arithmetic expressions).
We assume that Apple Clang has all the bugs of all the Clangs.

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

Followup to D96345, handle unary shuffles of binops (as well as binary shuffles) if we can merge the shuffle with inner operand shuffles.

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

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

Prior to e0d01294, all tests used a
random directory name, but now it is deterministic, based on the
test name. This change was done under the assumption that the filename
portion of the cwd is unique across tests that use the filesystem
test temporary directories.

When running tests locally, the cwd of the test is something like
"<build-dir>/test/<test path>/Output/copy_assign.pass.cpp.dir",
and the filename portion, "copy_assign.pass.cpp.dir", is used as
base for the temp directory names.

The change noted that there's a risk for race conditions if multiple
threads within one test try to create temp directories in parallel, but
that doesn't really happen in practice.

However, if running tests with a large number of parallel workers,
multiple tests with the same filename portion, e.g. "copy_assign.pass.cpp.dir",
can run in parallel, leading to race conditions across processes.

Therefore, add a hash of the full cwd to distinguish such cases
from each other.

Secondly, don't use two separate levels of temporary directories
(<base>/static_env.0). When cleaning up, only the individual
directory is removed, leaving the empty intermediate directory
behind littering the temp directory.

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

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

This requires changes to TableGen files and some C++ files due to
incompatible multiclass template arguments that slipped through
before the improved handling.

Replace the unknown operand used for immediate operands for DIV/MUL with a fixed 16-bit immediate.

This is required since the assembly parser generator requires that all operands are typed.

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

At the moment "link.exe" is hard-coded as default linker in MSVC.cpp,
so there's no way to use LLD as default linker for MSVC driver.

This patch adds checking of CLANG_DEFAULT_LINKER to MSVC.cpp and
updates unit-tests that expect link.exe linker to explicitly select it
via -fuse-ld=link, so that buildbots and other builds that set
-DCLANG_DEFAULT_LINKER=foobar don't fail these tests.

This is a squash of
- https://reviews.llvm.org/D98493 (MSVC.cpp change) and
- https://reviews.llvm.org/D98862 (unit-tests change)

Reviewed By: maxim-kuvyrkov

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

This patch adds support for intrinsic overloading on unnamed types.

This fixes PR38117 and PR48340 and will also be needed for the Full Restrict Patches (D68484).

The main problem is that the intrinsic overloading name mangling is using 's_s' for unnamed types.
This can result in identical intrinsic mangled names for different function prototypes.

This patch changes this by adding a '.XXXXX' to the intrinsic mangled name when at least one of the types is based on an unnamed type, ensuring that we get a unique name.

Implementation details:
- The mapping is created on demand and kept in Module.
- It also checks for existing clashes and recycles potentially existing prototypes and declarations.
- Because of extra data in Module, Intrinsic::getName needs an extra Module* argument and, for speed, an optional FunctionType* argument.
- I still kept the original two-argument 'Intrinsic::getName' around which keeps the original behavior (providing the base name).
-- Main reason is that I did not want to change the LLVMIntrinsicGetName version, as I don't know how acceptable such a change is
-- The current situation already has a limitation. So that should not get worse with this patch.
- Intrinsic::getDeclaration and the verifier are now using the new version.

Other notes:
- As far as I see, this should not suffer from stability issues. The count is only added for prototypes depending on at least one anonymous struct
- The initial count starts from 0 for each intrinsic mangled name.
- In case of name clashes, existing prototypes are remembered and reused when that makes sense.

Reviewed By: fhahn

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

Also remove populate patterns function and binary annotation name option.

Reviewed By: ftynse

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

Clang currently automates a fair amount of diagnostic checking for
declaration attributes based on the declarations in Attr.td. It checks
for things like subject appertainment, number of arguments, language
options, etc. This patch uses the same machinery to perform diagnostic
checking on statement attributes.

When a D-Form instruction is fed by an add-immediate, we attempt
to merge the two immediates to form a single displacement so we
can remove the add-immediate.

However, we don't check whether the new displacement fits into
a 16-bit signed immediate field early enough. Namely, we do a
sign-extend from 16 bits first which will discard high bits and
then we check whether the result is a 16-bit signed immediate.
It of course will always be.

Move the check prior to the sign extend to ensure we are checking
the correct value.

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

This patch consists of the initial changes to help distinguish between text and binary content correctly on z/OS. I would like to get feedback from Windows users on setting OF_None for all ToolOutputFiles. This seems to have been done as an optimization to prevent CRLF translation on Windows in the past.

Reviewed By: zibi

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

This is in preparation of changes in this area (such as D98789 and D98906).

Reviewed By: RKSimon

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

This makes it simpler to determine when two registers are actually the
same vs just partially aliasing.

The only real caveat is that it becomes impossible to know which name
was used for the register previously. (i.e. parsing assembly and then
disassembling it can result in the register name changing.)

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

This is required in order to determine during disassembly whether a
Reg bead without associated DA bead is referring to a data register.

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

This is redundant because we have already checked that we can't handle
divergent 64-bit atomic operands.

This reverts commit d09adfd3.

That commit caused failures in
clang-tidy/infrastructure/validate-check-names.cpp on windows
buildbots.

That change exposed a surprising issue, not directly related to
this change in itself, but in how TestRunner quotes command line
arguments that later are going to be interpreted by a msys based
tool (like grep.exe, when provided by Git for Windows). This
worked accidentally before, when grep was invoked via not.exe
which took a more conservative approach to windows argument quoting.

TestExitDuringExpression test_exit_before_one_thread_unwind fails
sporadically on both Arm and AArch64 linux buildbots.
This seems like a thread timing issue. I am marking it skip for now.

Split off from D98857

https://reviews.llvm.org/D98866

https://llvm.discourse.group/t/rfc-add-linalg-tileop/2833

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

All users have been converted to gpu::SerializeToBlobPass.

Reviewed By: ftynse

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

gcc complained with
../lib/Target/NVPTX/NVPTXLowerArgs.cpp:203:2: warning: extra ';' [-Wpedantic]
  203 | };
      |  ^

In preparation for https://reviews.llvm.org/D98925

When running in a Windows Container, the Git for Windows Unix tools
(C:\Program Files\Git\usr\bin) just hang if this variable isn't
passed through.

Currently, running the LLVM/clang tests in a Windows Container fails
if that directory is added to the path, but succeeds after this change.
(After this change, the previously used GnuWin tools can be left out
entirely, too, as lit automatically picks up the Git for Windows tools
if necessary.)

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

This was suggested in the review of D98139.

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

Keep running "not --crash" via the external "not" executable, but
for plain negations, and for cases that use the shell "!" operator,
just skip that argument and invert the return code.

The libcxx tests only use the shell operator "!" for negations,
never the "not" executable, because libcxx tests can be run without
having a fully built llvm tree available providing the "not"
executable.

This allows using the internal shell for libcxx tests.

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

This change combines for ROCm what was done for CUDA in D97463, D98203, D98360, and D98396.

I did not try to compile SerializeToHsaco.cpp or test mlir/test/Integration/GPU/ROCM because I don't have an AMD card. I fixed the things that had obvious bit-rot though.

Reviewed By: whchung

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