We can't declare unique_function that has in its arguments a reference to
a template type with an incomplete argument.
For instance, we can't declare unique_function<void(SmallVectorImpl<A>&)>
when A is forward declared.

This is because SFINAE will trigger a hard error in this case, when instantiating
IsSizeLessThanThresholdT with the incomplete type.

This patch specialize AdjustedParamT for references to remove this error.

Committed on behalf of: @math-fehr (Fehr Mathieu)

Reviewed By: DaniilSuchkov, yrouban

This helps to distinguish such tests from successfully passed ones.

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

This updates the googletest format to support tests that use GTEST_SKIP(),
which is now available with the updated googletest framework.

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

Instead of ignoring flto=auto and -flto=jobserver, treat them as -flto
and pass -flto=full along.

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

It's still the slowest test under our emulator.

The function `reduceOperationWidth` helps to legalize a vector
operation either by narrowing its type or by scalarizing the
operation itself. It currently supports instructions with one result.
This patch, in addition allows the same for instructions with two
results (for instance, G_SDIVREM).

Reviewed By: arsenm

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

Previously APFloat::convertToDouble may be called only for APFloats that
were built using double semantics. Other semantics like single precision
were not allowed although corresponding numbers could be converted to
double without loss of precision. The similar restriction applied to
APFloat::convertToFloat.

With this change any APFloat that can be precisely represented by double
can be handled with convertToDouble. Behavior of convertToFloat was
updated similarly. It make the conversion operations more convenient and
adds support for formats like half and bfloat.

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

I do not see any practical difference but technically
used.* variables are internal and a call to getGlobalVariable
misses true as a second argument. NFC as far as I can tell.

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

Reviewed By: stephan.yichao.zhao

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

This method is like StackTrace::Print but instead of printing to stderr
it copies its output to a user-provided buffer.

Part of https://reviews.llvm.org/D102451.

Reviewed By: vitalybuka, stephan.yichao.zhao

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

.byte supports string, so if the whole byte list are printable,
we can actually print the string for readability and LIT tests maintainence.

        .byte 'H,'e,'l,'l,'o,',,' ,'w,'o,'r,'l,'d
->
        .byte "Hello, world"

Reviewed By: hubert.reinterpretcast

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

If this happend we can't run corresponding test.

The dyld SPI used by debugserver (_dyld_process_info_create) has become
much slower in macOS BigSur 11.3 causing a significant performance
regression when attaching. This commit mitigates that by caching the
result when calling the SPI to compute the platform.

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

Remove the `nosync` attribute from the memory intrinsic definitions
(i.e. memset, memcpy, memmove).

Like native memory accesses, memory intrinsics can be volatile. This is
indicated by an immarg in the intrinsic call. All else equal, a volatile
memory intrinsic is `sync`, so we cannot annotate the intrinsic functions
themselves as `nosync`. The attributor and function-attr passes know to
take the volatile bit into account.

Since `nosync` is a default attribute, this means we have to stop using
the DefaultAttrIntrinsic tablegen class for memory intrinsics, and
specify all default attributes other than `nosync` explicitly.

Most of the test changes are trivial churn, but one test case
(in nosync.ll) was in fact incorrect before this change.

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

This change is generated by running update_test_checks.py. It serves to
make subsequent diffs easier to understand.

Put allocate/deallocate next to memory
access inside EXPECT_DEATH block.
This way we reduce probability that memory is not mapped
by unrelated code.

It's still not absolutely guaranty that mmap does not
happen so we repeat it few times to be sure.

Reviewed By: cryptoad

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

Now that we're passing -D_LIBCPP_BUILDING_LIBRARY to the libc++abi
build, -D_LIBCPP_ENABLE_CXX17_REMOVED_UNEXPECTED_FUNCTIONS is redundant
(https://github.com/llvm/llvm-project/blob/fb3a00c327df78eaa534e53ac6f07112e0585121/libcxx/include/exception#L120-L121
is the only use of _LIBCPP_ENABLE_CXX17_REMOVED_UNEXPECTED_FUNCTIONS in
libc++, and that conditional also checks for _LIBCPP_BUILDING_LIBRARY).

Reviewed By: #libc_abi, phosek

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

Previously we simply didn't check this. Prereq to make the test suite
pass with ghash enabled by default.

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

Accesses to global module LDS variable start from null,
but kernel also thinks its variables start address is
null. Fixed by not using a null as an address.

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

This will help to see result of D102462.

Test was generated with
./llvm/utils/update_test_checks.py llvm/test/Instrumentation/AddressSanitizer/fake-stack.ll --opt-binary <build_dir>/bin/opt

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

Reduce memory footprint of AST Reader/Writer:
1. Adjust internal data containers' element type.
2. Switch to set for deduplication of deferred diags.

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

Drop the Affine dialect EDSC subdirectory and update all uses.

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

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

Fixes the clang build of flang/runtime/transformational.cpp.

variables emitted on both host and device side with different addresses
when ODR-used by host function should not cause device side counter-part
to be force emitted.

This fixes the regression caused by https://reviews.llvm.org/D102237

Reviewed by: Artem Belevich

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

This patch adds supports for inline assembly operands and some simple
operand constraints, including register and constant operands.

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

Add `-ffixed-a[0-6]` and `-ffixed-d[0-7]` and the corresponding
subtarget features to prevent certain register from being allocated.

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

A recent commit (e00a170) inadvertently exposed the Reshape runtime
function as being extern "C", for which it is not yet ready, leading
to a valid warning from clang that we treat as an error.  Patch.

Define APIs, naively implement, and add basic sanity unit tests for
the transformational intrinsic functions CSHIFT, EOSHIFT, PACK,
SPREAD, TRANSPOSE, and UNPACK.  These are the remaining transformational
intrinsic functions that rearrange data without regard to type
(except for default boundary values in EOSHIFT); RESHAPE was already
in place as a stress test for the runtime's descriptor handling
facilities.

Code is in place to create copies of allocatable/automatic
components when transforming arrays of derived type, but it won't
do anything until we have derived type information being passed to the
runtime from the frontend.

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

Drop the MemRef dialect EDSC subdirectory and update all uses.

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

It turns out we have not correctly supported exception spec all along in
Emscripten EH. Emscripten EH supports `throw()` but not `throw` with
types. See https://bugs.llvm.org/show_bug.cgi?id=50396.

Wasm EH also only supports `throw()` but not `throw` with types, and we
have been printing a warning message for the latter. This prints the
same warning message for `throw` with types when Emscripten EH is used,
or more precisely, when Wasm EH is not used. (So this will print the
warning messsage even when `-fno-exceptions` is used but I think that
should be fine. It's cumbersome to do a complilcated option checking in
CGException.cpp and options checkings are mostly done in elsewhere.)

Reviewed By: dschuff, kripken

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

In D98289#inline-939112 @dblaikie said:
  Perhaps this could be more informative about what makes the range list
  index of 0 invalid? "index 0 out of range of range list table (with
  range list base 0xXXX) with offset entry count of XX (valid indexes
  0-(XX-1))" Maybe that's too verbose/not worth worrying about since
  this'll only be relevant to DWARF producers trying to debug their
  DWARFv5, maybe no one will ever see this message in practice. Just
  a thought.

Reviewed By: dblaikie

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

[SelectionDAG][Mips][PowerPC][RISCV][WebAssembly] Teach computeKnownBits/ComputeNumSignBits about atomics

Unlike normal loads these don't have an extension field, but we know
from TargetLowering whether these are sign-extending or zero-extending,
and so can optimise away unnecessary extensions.

This was noticed on RISC-V, where sign extensions in the calling
convention would result in unnecessary explicit extension instructions,
but this also fixes some Mips inefficiencies. PowerPC sees churn in the
tests as all the zero extensions are only for promoting 32-bit to
64-bit, but these zero extensions are still not optimised away as they
should be, likely due to i32 being a legal type.

This also simplifies the WebAssembly code somewhat, which currently
works around the lack of target-independent combines with some ugly
patterns that break once they're optimised away.

Re-landed with correct handling in ComputeNumSignBits for Tmp == VTBits,
where zero-extending atomics were incorrectly returning 0 rather than
the (slightly confusing) required return value of 1.

Re-landed again after D102819 fixed PowerPC to correctly zero-extend all
of its atomics as it claimed to do, since the combination of that bug
and this optimisation caused buildbot regressions.

Reviewed By: RKSimon, atanasyan

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

[libomptarget] Improve dlwrap compile time error diagnostic

The dlwrap interface takes an explict arity, e.g. DLWRAP(cuAlloc, 2);
This probably can't be eliminated as it controls the argument list of an
external symbol, not an inline header function. If the arity given is too
big, the error from clang referring to the line is in the middle of
implementation details.

/usr/lib/gcc/x86_64-linux-gnu/10/../../../../include/c++/10/tuple:1277:7: error: static_assert failed
      due to requirement '0UL < tuple_size<std::tuple<>>::value' "tuple index is in range"
      static_assert(__i < tuple_size<tuple<>>::value,
      ^             ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/usr/lib/gcc/x86_64-linux-gnu/10/../../../../include/c++/10/tuple:1260:7: ...
/usr/lib/gcc/x86_64-linux-gnu/10/../../../../include/c++/10/tuple:1260:7: ...
/home/amd/llvm-project/openmp/libomptarget/include/dlwrap.h:93:27 ...

/home/amd/llvm-project/openmp/libomptarget/plugins/cuda/dynamic_cuda/cuda.cpp:34:1: note: in
      instantiation of template class 'dlwrap::trait<cudaError_enum (*)(unsigned long *, unsigned
      long)>::arg<2>' requested here
DLWRAP(cuMemAlloc, 3);
^
/home/amd/llvm-project/openmp/libomptarget/include/dlwrap.h:51:31: ...
/home/amd/llvm-project/openmp/libomptarget/include/dlwrap.h:166:3: ...
/home/amd/llvm-project/openmp/libomptarget/include/dlwrap.h:133:3: ...
/home/amd/llvm-project/openmp/libomptarget/include/dlwrap.h:186:37: ...

If the arity is too small, the diagnostic is better:

cuda/dynamic_cuda/cuda.cpp:34:1: error: too few
      arguments to function call, expected 2, have 1
DLWRAP(cuMemAlloc, 1);

This patch changes the diagnostic to:

cuda/dynamic_cuda/cuda.cpp:34:1: error:
      static_assert failed due to requirement '1 == trait<cudaError_enum (*)(unsigned long *, unsigned
      long)>::nargs' "Arity Error"
DLWRAP(cuMemAlloc, 1);

or

cuda/dynamic_cuda/cuda.cpp:34:1: error:
      static_assert failed due to requirement '3 == trait<cudaError_enum (*)(unsigned long *, unsigned
      long)>::nargs' "Arity Error"
DLWRAP(cuMemAlloc, 3);

Reviewed By: tianshilei1992

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

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

This reverts commit 4bf69fb5.

This broke spec2k6/403.gcc under -global-isel. Details to follow once I've
reduced the problem.