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

This reverts commit dbf47d22.

Reapply https://reviews.llvm.org/D116784 now that
https://reviews.llvm.org/D118413 has landed with a couple of fixes:
* fix raw profile reader unaligned access identified by ubsan
* fix windows build by using MOCK_CONST_METHOD3 instead of MOCK_METHOD.

-O1 doesn't seem necessary here.

Reviewed By: vitalybuka

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

When not going through the main Clang->LLVM type cache, we'd
accidentally create multiple different opaque types for a member pointer
type.

This allows us to remove the -verify-type-cache flag now that
check-clang passes with it on. We can do the verification in expensive
builds. Previously microsoft-abi-member-pointers.cpp was failing with
-verify-type-cache.

I suspect that there may be more issues when we have multiple member
pointer types and we clear the cache, but we can leave that for later.

Followup to D118744.

Reviewed By: rnk

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

This makes the function independent of shared state in ILV (ensures no
new dependencies on things like the cost model are introduced) and allows
for use directly in recipe's ::execute functions.

This introduces the new __ARM_FEATURE_MOPS ACLE feature test macro,
which signals the availability of the new Armv8.8-A/Armv9.3-A
instructions for standardising memcpy, memset and memmove operations.

This patch supersedes the one from https://reviews.llvm.org/D116160.

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

This symbol has been exported (as an internal GLIBC_PRIVATE symbol) from libc.so.6 starting with glibc 2.34. glibc uses it internally for its libthread_db implementation to enable thread debugging on GDB, so it is unlikely to go away for now.

Fixes #52989.

Reviewed By: #sanitizers, MaskRay, vitalybuka

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

Although type punning is defined for union in C, it is UB in C++.
This patch introduces a bit_cast function to convert between types in a safe way.

This is necessary to get llvm-libc compile with GCC.
This patch is extracted from D119002.

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

Summary: Shared object instrumentation test

Test Plan: bin/llvm-lit -a bolt/test/X86/internal-call-instrument-so.s

Reviewers: rafauler

FBD34064557

Reported:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1005195

llvm.insertvalue and llvm.extractvalue need LLVM primitive type
for the indexing operands. While upstreaming the TargetRewrite pass the change
was made from i32 to index without knowing this restriction. This patch reverts
back the types used for indexing in the two ops created in this pass.

the error you will receive when lowering to LLVM IR with the current code
is the following:

```
 'llvm.insertvalue' op operand #1 must be primitive LLVM type, but got 'index'
```

Reviewed By: jeanPerier, schweitz

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

Previously, _LIBCPP_ABI_UNSTABLE would be used interchangeably with
_LIBCPP_ABI_VERSION >= 2. This was confusing and creating unnecessary
complexity.

This patch removes _LIBCPP_ABI_UNSTABLE -- instead, the LIBCXX_ABI_UNSTABLE
CMake option will result in the LIBCXX_ABI_VERSION being set to '2', the
current unstable ABI. As a result, in the code, we only have _LIBCPP_ABI_VERSION
to check in order to query the current ABI version.

As a fly-by, this also defines the ABI namespace during CMake configuration
to reduce complexity in __config. I believe it was previously done this
way because we used to try to use __config_site as seldom as possible.
Now that we always ship a __config_site, it doesn't really matter and
I think being explicit about how the library is configured in the __config_site
is actually a feature.

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

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

Implements optional attribute or type parameters, including support for such parameters in the assembly format `struct` directive. Also implements optional groups.

Depends on D117971

Reviewed By: rriddle

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

Add case to handle 0-D vectors in FlattenContiguousRowMajorTransferWritePattern and FlattenContiguousRowMajorTransferReadPattern.

For 0-D as well as 1-D vectors, both these patterns should
return a failure as there is no need to collapse the shape
of the source. Currently, only 1-D vectors were handled. This
patch handles the 0-D case as well.

Reviewed By: Benoit, ThomasRaoux

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

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

The above change assumed that malloc (and friends) would always
allocate memory to getNewAlign(), even for allocations which have a
smaller size. This is not actually required by spec (a 1-byte
allocation may validly have 1-byte alignment).

Some real-world malloc implementations do not provide this guarantee,
and thus this optimization is breaking programs.

Fixes #53540

This reverts commit c2297544.

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

Debuginfod can pull in libcurl as a dependency, which isn't appropriate
for libLLVM. (See
https://gitlab.freedesktop.org/mesa/mesa/-/issues/5732).

This change breaks out debuginfod into a separate non-component library
that can be used directly in llvm-symbolizer. The tool can inject
debuginfod into the Symbolizer library via an abstract DebugInfoFetcher
interface, breaking the dependency of Symbolizer on debuinfod.

See https://github.com/llvm/llvm-project/issues/52731

Reviewed By: phosek

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

The original warning added in D115501 when pacbti is used with an
incompatible architecture was not exactly correct because it was
not really ignored and can affect codegen.

Therefore reword to say that the pacbti option is incompatible with
the given architecture.

Reviewed By: chill

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

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

These changes make the Clang parser recognize expression parameter pack
expansion and initializer lists in attribute arguments. Because
expression parameter pack expansion requires additional handling while
creating and instantiating templates, the support for them must be
explicitly supported through the AcceptsExprPack flag.

Handling expression pack expansions may require a delay to when the
arguments of an attribute are correctly populated. To this end,
attributes that are set to accept these - through setting the
AcceptsExprPack flag - will automatically have an additional variadic
expression argument member named DelayedArgs. This member is not
exposed the same way other arguments are but is set through the new
CreateWithDelayedArgs creator function generated for applicable
attributes.

To illustrate how to implement support for expression pack expansion
support, clang::annotate is made to support pack expansions. This is
done by making handleAnnotationAttr delay setting the actual attribute
arguments until after template instantiation if it was unable to
populate the arguments due to dependencies in the parsed expressions.

These were all the non OS agnostic implementations I could find in general directories.

Currently none of these functions are actually enabled, but for when they do it makes sense that they be in linux/ specific directories.

Reviewed By: sivachandra

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

As long as *all* the invokes in the set are indirect,
we can merge them, but don't merge direct invokes into the set,
even though it would be legal to do.

[SimplifyCFG] 'merge compatible invokes': don't create trivial PHI's with all-identical incoming values

We can select _vgprcd versions of MAI instructions and have no
AGPRs with the whole budget left for VGPRs if:

1. This is a kernel;
2. It has no calls;
3. It runs at least on 2 waves thus having not more that 256 VGPRs.
4. There is no inline asm requesting AGPRs.

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

There are a few different test passes that check elementwise fusion in
Linalg. Consolidate them to a single pass controlled by different pass
options (in keeping with how `TestLinalgTransforms` exists).

This patch adds partial lowering of the "GET_ENVIRONMENT_VARIABLE" intrinsic
to the backend runtime hook implemented in patches D111394 and D112698.
It also renames the `isPresent` lambda to `isAbsent` and moves it out to
its own function in `Command.cpp`. Corresponding comment fixes for this
are also modified. Lastly it adds the i1 type to
`RuntimeCallTestBash.h`.

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

Most Intel CPU scheduler files lumped the immediate and 1 instructions
together, but uops.info shows they are quite different.

For the most part the by 1 instructions were pretty accurate to the uops.info
data except the latency was 3 instead of 2 as uops.info indicates.

The by immediate instructions need 7 or 8 uops and have higher latency.

It looks like the 8-bit by immediate instructions may need even more
uops, but I just lumped them with the 16/32/64.

Noticed while checking out PR53648. So mostly I cared about the by 1
instructions.

Reviewed By: RKSimon, pengfei

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

Implement P2128R6 in C++23 mode.

Unlike GCC's implementation, this doesn't try to recover when a user
meant to use a comma expression.

Because the syntax changes meaning in C++23, the patch is *NOT*
implemented as an extension. Instead, declaring an array with not
exactly 1 parameter is an error in older languages modes. There is an
off-by-default extension warning in C++23 mode.

Unlike the standard, we supports default arguments;

Ie, we assume, based on conversations in WG21, that the proposed
resolution to CWG2507 will be accepted.

We allow arrays OpenMP sections and C++23 multidimensional array to
coexist:

[a , b] multi dimensional array
[a : b] open mp section
[a, b: c] // error

The rest of the patch is relatively straight forward: we take care to
support an arbitrary number of arguments everywhere.

This patch replaces the function we emit the remark on when we run into
the fix-point limit. Previously we got a function to emit a remark on
from the worklist's associated function. However, the worklist may not
always have an associated function in the case of global variables.
Replace this with the function set, and if there are no functions don't
emit the remark.

Reviewed By: jdoerfert

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

This patch manually adds the runtime include files to the list of
dependencies when we build the bitcode runtime library. Previously if
only the header was changed we would not recompile the source files.
The solution used here isn't optimal because every source file not has a
dependency on each header file regardless of if it was actually used by
that file.

Reviewed By: tianshilei1992

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

The documentation for the official (downstream) Qualcomm Hexagon Clang
states that -mhvx sets the HVX version to be the same as the CPU version.
The current implementation upstream would use the most recent versioned
-mhvx= flag first (if present), then the CPU version. Change the upstream
behavior to match the documented behavior of the downstream compiler.

Among many FoldingSet users most notable seem to be ASTContext and CodeGenTypes.
The reasons that we spend not-so-tiny amount of time in FoldingSet calls from there, are following:

  1. Default FoldingSet capacity for 2^6 items very often is not enough.
     For PointerTypes/ElaboratedTypes/ParenTypes it's not unlikely to observe growing it to 256 or 512 items.
     FunctionProtoTypes can easily exceed 1k items capacity growing up to 4k or even 8k size.

  2. FoldingSetBase::GrowBucketCount cost itself is not very bad (pure reallocations are rather cheap thanks to BumpPtrAllocator).
     What matters is high collision rate when lot of items end up in same bucket slowing down FoldingSetBase::FindNodeOrInsertPos and trashing CPU cache
     (as items with same hash are organized in intrusive linked list which need to be traversed).

This change address both issues by increasing initial size of FoldingSets used in ASTContext and CodeGenTypes.

Extracted from: https://reviews.llvm.org/D118385

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

Static functions in a header cause spurious unused function warnings.