Discussed here: https://reviews.llvm.org/D119061#3310822

Reviewed By: aaron.ballman

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

OpenCL C 3.0 __opencl_c_subgroups feature is slightly different
then other equivalent features and extensions (fp64 and 3d image writes):
OpenCL C 3.0 device can support the extension but not the feature.
cl_khr_subgroups requires subgroup independent forward progress.

This patch adjusts the check which is used when translating language
builtins to check either the extension or feature is supported.

Reviewed By: Anastasia

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

Fixed mistaken iterations distribution between different target regions.

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

This patch adds an option (no-clang-tools) to disable building clang-tools-extra when
performing release testing. Prior to this patch, clang-tools-extra was built by default,
but on some platforms (such as AIX), clang-tools-extra is not supported, and so we do
not normally build it. Furthermore, this change should not change the invocation for
targets that build clang-tools-extra normally.

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

Rather than checking that the type is the same (which is always
the case, given how these are part of the same phi) check that the
source element type is the same. With opaque pointers, this is no
longer implied.

Masked reduction intrinsics are specical cases which don't need to have policy
operand. The mask only affects which elements are read. It doesn't effect the
destination register.
The reduction intrinsics have a dedicated destination operand. If it
is undef, we use tail agnostic. If it not undef we use tail
undisturbed.

Co-Authored-by: Craig Topper <craig.topper@sifive.com>

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

When lowering to memrefCopy call, the size for i1 type was calculated as 0.
Instead of using getTypeSizeInBits() and dividing by 8, we should just use getTypeSize().

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

OpenCL C 3.0 introduces optionality to some builtins, in particularly
to those which are conditionally supported with pipe, device enqueue
and generic address space features.

The idea is to conditionally support such builtins depending on the language options
being set for a certain feature. This allows users to define functions with names
of those optional builtins in OpenCL (as such names are not reserved).

Reviewed By: Anastasia

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

The unqualified name grammar includes <ctor-dtor-name>, but we handle
that specially in parseNestedName.  This is a little awkward.  We can
pass in the current scope and have parseUnqualifiedName deal with
cdtors too.  That also allows a couple of other simplifications:

1) parseUnqualifiedName can also build up the NestedName, when the
provided scope is non-null.  Which means ...

2) parseUnscopedName can pass a "std" scope in (and tailcall).

3) ... and also parseNestedName need not construct the nestedname itself.

4) also parseNestedName's detection of a cdtor-name doesn't have to
rule out a decomposition name anymore.

This change also makes adding module demangling more
straight-forwards, btw.

Reviewed By: ChuanqiXu

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

To avoid incorrectly merging GEPs with different source types
under opaque pointers.

To avoid increasing the Expression structure size, this reuses the
existing type member. The code does not rely on this to be the
expression result type, it's only used as a disambiguator.

Fixes: #53679

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

The lowering creates llvm.insertvalue with the rank value, so it needs to use
index type instead of 64 bit integer type. Otherwise, we get an error:

llvm.insertvalue' op Type mismatch: cannot insert 'i64' into '!llvm.struct<(i32, ptr<i8>)>'

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

Reviewed By: Groverkss

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

Two GEPs with same indices but different source type are not the
same.

Worth noting that FunctionComparator already handles this correctly.

This will be necessary later when we add support for evaluating logic
expressions such as && and ||.

This is part of the implementation of the dataflow analysis framework.
See "[RFC] A dataflow analysis framework for Clang AST" on cfe-dev.

Reviewed-by: xazax.hun

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

We run bots on a shared machine and under high load
this test sometimes segfaults.

https://lab.llvm.org/buildbot/#/builders/185/builds/1368

==1952234==XRay FDR init successful.
==1952234==XRay FDR: Not flushing to file, 'no_file_flush=true'.
<...>fdr-reinit.cpp.script: line 4: 1952234 Segmentation fault
XRAY_OPTIONS="verbosity=1" <...>/fdr-reinit.cpp.tmp

Looking at the printed output I think it's happening at:
// Finally, we should signal the sibling thread to stop.
keep_going.clear(std::memory_order_release);

Disabling the test while I try to reproduce.

Newly created fneg was built after some of it's uses in some cases.
Now it will be built immediately after instruction whose dst it negates.

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

I've split the git archive generation into three steps:

1. generate pure tarball
2. append top-level cmake directory to all tarballs
3. compress the archive

This was inspired by D118252 and can be considered an alternative
approach for all projects to have access to the shared cmake
directory when building in standalone mode.

When generating source tarballs on my local laptop it takes 9 minutes and 45 seconds WITH this patch applied. When this patch is not applied, it takes 9minutes and 38 seconds. That means, this patch introduces a slowdown of 7 seconds, which seems fair.

Reviewed By: tstellar

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

The pointer is always dereferenced, so assert the cast is correct (which it should be as we just created that ScalableVectorType) instead of returning nullptr

The pointer is always dereferenced by isCompareUsedByBranch, so assert the cast is correct instead of returning nullptr

Fixup for experimental m68k target after D119359

Add the atomic overloads for the `global` and `local` address spaces,
which are new in OpenCL 3.0.  Ensure the preexisting `generic`
overloads are guarded by the generic address space feature macro.

Ensure a subset of the atomic builtins are guarded by the
`__opencl_c_atomic_order_seq_cst` and `__opencl_c_atomic_scope_device`
feature macros, and enable those macros for SPIR/SPIR-V targets in
`opencl-c-base.h`.

Also guard the `cl_ext_float_atomics` builtins with the atomic order
and scope feature macros.

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

When deciding where to split a block to insert stack guard checks, we should
move past any debug instructions we see that might (e.g.) be separating a tail
call from its frame wrangling.

SCCP requires that the load/store type and global type are the
same (it does not support bitcasts of tracked globals). With
typed pointers this was implicitly enforced.

Cf. https://github.com/llvm/llvm-project/issues/44542.
Cf. https://github.com/llvm/llvm-project/commit/ae1b7859cbd61d2284d9690bc53482d0b6a46f63.

`CallDescriptions` for builtin functions relaxes the match rules
somewhat, so that the `CallDescription` will match for calls that have
some prefix or suffix. This was achieved by doing a `StringRef::contains()`.
However, this is somewhat problematic for builtins that are substrings
of each other.

Consider the following:

`CallDescription{ builtin, "memcpy"}` will match for
`__builtin_wmemcpy()` calls, which is unfortunate.

This patch addresses/works around the issue by checking if the
characters around the function's name are not part of the 'name'
semantically. In other words, to accept a match for `"memcpy"` the call
should not have alphanumeric (`[a-zA-Z]`) characters around the 'match'.

So, `CallDescription{ builtin, "memcpy"}` will not match on:

 - `__builtin_wmemcpy: there is a `w` alphanumeric character before the match.
 - `__builtin_memcpyFOoBar_inline`: there is a `F` character after the match.
 - `__builtin_memcpyX_inline`: there is an `X` character after the match.

But it will still match for:
 - `memcpy`: exact match
 - `__builtin_memcpy`: there is an _ before the match
 - `__builtin_memcpy_inline`: there is an _ after the match
 - `memcpy_inline_builtinFooBar`: there is an _ after the match

Reviewed By: NoQ

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

As usual with that header cleanup series, some implicit dependencies now need to
be explicit:

llvm/MC/MCParser/MCAsmParser.h no longer includes llvm/MC/MCParser/MCAsmLexer.h

Preprocessed lines to build llvm on my setup:
after:  1068185081
before: 1068324320

So no compile time benefit to expect, but we still get the looser coupling
between files which is great.

Discourse thread: https://discourse.llvm.org/t/include-what-you-use-include-cleanup
Differential Revision: https://reviews.llvm.org/D119359

This patch simply adds an optional garbage collector attribute to LLVMFuncOp which maps 1:1 to the "gc" property of functions in LLVM.

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

This fold could use a rewrite to an offset-based implementation,
but for now make sure it doesn't crash with opaque pointers.

In Clang we can attach TBAA metadata based on the load/store intrinsics
based on the operation's element type.

This also contains changes to InstCombine where the AArch64-specific
intrinsics are transformed into generic LLVM load/store operations,
to ensure that all metadata is transferred to the new instruction.

There will be some further work after this patch to also emit TBAA
metadata for SVE's gather/scatter- and struct load/store intrinsics.

Reviewed By: paulwalker-arm

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

This allows operations to control the block ids used by the printer in nested regions.

Reviewed By: Mogball

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