Summary:
Support ConstantInt::get() and Constant::getAllOnesValue() for scalable
vector type, this requires ConstantVector::getSplat() to take in 'ElementCount',
instead of 'unsigned' number of element count.

This change is needed for D73753.

Reviewers: sdesmalen, efriedma, apazos, spatel, huntergr, willlovett

Reviewed By: efriedma

Subscribers: tschuett, hiraditya, rkruppe, psnobl, cfe-commits, llvm-commits

Tags: #llvm

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

This patch allows ISD::FSHR(i32) patterns to lower to ALIGNBIT instructions.

This improves test coverage of ISD::FSHR matching - x86 has both FSHL/FSHR instructions and we prefer FSHL by default.

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

function and an overridden function until we know whether the overriding
function is deleted.

We previously did these checks when we first built the declaration,
which was too soon in some cases. We now defer all these checks to the
end of the class.

Also add missing check that a consteval function cannot override a
non-consteval function and vice versa.

Fix bug identified by https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=21167, foldVSelectOfConstants must ensure that the 2 build vectors have scalars of the same type before trying to compare APInt values.

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

Summary:
Using the default DAG.UnrollVectorOp on v16i8 and v8i16 vectors
results in i8 or i16 nodes being inserted into the SelectionDAG. Since
those are illegal types, this causes a legalization assertion failure
for some code patterns, as uncovered by PR45178. This change unrolls
shifts manually to avoid this issue by adding and using a new optional
EVT argument to DAG.ExtractVectorElements to control the type of the
extract_element nodes.

Reviewers: aheejin, dschuff

Subscribers: sbc100, jgravelle-google, hiraditya, sunfish, zzheng, llvm-commits

Tags: #llvm

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

In addition to the commit rG352f16db87f583ec7f55f8028647b5fd8616111f,
this one fixes settings behavior on clearing - the setting should be
reverted to their default value, not an empty one.

This has very little impact on build time, but is a mechanical pre-req
to removing the OpenMPClause.h include, which matters. Most of these
pretty print methods require Expr to be complete.

Use castAs as we know the cast should succeed (and castAs will assert if it doesn't) and we're dereferencing it directly in the BuildRCBlockVarRecordLayout call.

CGOpenMPRuntime::emitDeclareTargetVarDefinition - fix static analyzer null dereference warning. NFCI.

All paths test for or dereference the VD pointer, so just assert that its not null.

Repeat the assertion that we already have in hasDomain for addDomain and setSingleDomain.

This commit is likely causing clang-with-lto-ubuntu to fail
http://lab.llvm.org:8011/builders/clang-with-lto-ubuntu/builds/16052

Also causes PR45185.

This reverts commit f1ac5d22.

Summary: This adds a new module to enforce standards specific to the llvm-libc project. This change also adds the first check which restricts user from including system libc headers accidentally which can lead to subtle bugs that would be a challenge to detect.

Reviewers: alexfh, hokein, aaron.ballman

Reviewed By: aaron.ballman

Subscribers: juliehockett, arphaman, jfb, abrachet, sivachandra, Eugene.Zelenko, njames93, mgorny, xazax.hun, MaskRay, cfe-commits

Tags: #clang-tools-extra, #libc-project, #clang

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

This is to replace the optimization from the SIOptimizeExecMaskingPreRA.
We have less opportunities in the control flow lowering because many
VGPR copies are still in place and will be removed later, but we know
for sure an instruction is SI_END_CF and not just an arbitrary S_OR_B64
with EXEC.

The subsequent change needs to convert s_and_saveexec into s_and and
address new TODO lines in tests, then code block guarded by the
-amdgpu-remove-redundant-endcf option in the pre-RA exec mask optimizer
will be removed.

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

Summary:
This improves unwind performance quite substantially, and follows
a somewhat similar approach used in libgcc_s as described in the
thread here:

https://gcc.gnu.org/ml/gcc/2005-02/msg00625.html

On certain extremely exception heavy internal tests, the time
drops from about 80 minutes to about five minutes.

Subscribers: libcxx-commits

Tags: #libc

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

Use GraphTraits in the implementation of the GraphDiff's own GraphTraits
so GraphDiff can be used across all graph types that provide
GraphTraits.

Also use partial template specializations to make the traits a bit more
compact.

Reviewers: asbirlea

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

clang accepts a TU containing just:

  __SVInt8_t x;

However, sizeless types are not allowed to have static or thread-local
storage duration and trying to code-generate the TU triggers an LLVM
fatal error:

  Globals cannot contain scalable vectors
  <vscale x 16 x i8>* @x
  fatal error: error in backend: Broken module found, compilation aborted!

This patch adds an associated clang diagnostic.

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

Interface provides uniform access to the the derived attribute query method.

Add YAML traits for the ConstString and FileSpec classes so they can be
serialized as part of ProcessInfo. The latter needs to be serializable
for the reproducers.

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

It would be difficult to guarantee atomicity for sizeless types,
so the SVE ACLE makes atomic sizeless types invalid.  As it happens,
we already rejected them before the patch, but for the wrong reason:

  error: _Atomic cannot be applied to type 'svint8_t' (aka '__SVInt8_t')
  which is not trivially copyable

The SVE types should be treated as trivially copyable; a later
patch fixes that.

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

A previous patch rejected alignof for sizeless types.  This patch
extends that to cover the "aligned" attribute and _Alignas.  Since
sizeless types are not meant to be used for long-term data, cannot
be used in aggregates, and cannot have static storage duration,
there shouldn't be any need to fiddle with their alignment.

Like with alignof, this is a conservative position that can be
relaxed in future if it turns out to be too restrictive.

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

clang current accepts:

  void foo1(__SVInt8_t *x, __SVInt8_t *y) { *x = *y; }
  void foo2(__SVInt8_t *x, __SVInt8_t *y) {
    memcpy(y, x, sizeof(__SVInt8_t));
  }

The first function is valid ACLE code and generates correct LLVM IR.
However, the second function is invalid ACLE code and generates a
zero-length memcpy.  The point of this patch is to reject the use
of sizeof in the second case instead.

There's no similar wrong-code bug for alignof.  However, the SVE ACLE
conservatively treats alignof in the same way as sizeof, just as the
C++ standard does for incomplete types.  The idea is that layout of
sizeless types is an implementation property and isn't defined at
the language level.

Implementation-wise, the patch adds a new CompleteTypeKind enum
that controls whether RequireCompleteType & friends accept sizeless
built-in types.  For now the default is to maintain the status quo
and accept sizeless types.  However, the end of the series will flip
the default and remove the Default enum value.

The patch also adds new ...CompleteSized... wrappers that callers can
use if they explicitly want to reject sizeless types.  The callers then
use diagnostics that have an extra 0/1 parameter to indicats whether
the type is sizeless or not.

The idea is to have three cases:

1. calls that explicitly reject sizeless types, with a tweaked diagnostic
   for the sizeless case

2. calls that explicitly allow sizeless types

3. normal/old-style calls that don't make an explicit choice either way

Once the default is flipped, the 3. calls will conservatively reject
sizeless types, using the same diagnostic as for other incomplete types.

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

This fixes an issue with clang issuing a warning about unknown CUDA SDK if it's
detected during non-CUDA compilation.

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

This patch adds C and C++ tests for various uses of SVE types.
The tests cover valid uses that are already (correctly) accepted and
invalid uses that are already (correctly) rejected.  Later patches
will expand the tests as they fix other cases.[*]

Some of the tests for invalid uses aren't obviously related to
scalable vectors.  Part of the reason for having them is to make
sure that the quality of the error message doesn't regress once/if
the types are treated as incomplete types.

[*] These later patches all fix invalid uses that are being incorrectly
    accepted.  I don't know of any cases in which valid uses are being
    incorrectly rejected.  In other words, this series is all about
    diagnosing invalid code rather than enabling something new.

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

Both these casts are immediately deferenced and the cast will assert for us that they are of the correct type.

One of the defining features of the SVE ACLE types is that they
are "sizeless"; see the SVE ACLE spec:

    https://developer.arm.com/docs/100987/0000/arm-c-language-extensions-for-sve

or the email message:

    http://lists.llvm.org/pipermail/cfe-dev/2019-June/062523.html

for a fuller definition of what that means.

This patch adds two associated type queries:

- isSizelessBuiltinType asks specifically about types that are built
  into clang.  It is effectively an enum range check.

- isSizelessType instead tests for any type that has the "sizeless" type
  property.  At the moment it only returns true for the built-in types,
  but it seems better not to hard-code that assumption throughout
  the codebase.  (E.g. we could in principle support some form of
  user-defined sizeless types in future.  Even if that seems unlikely
  and never actually happens, the possibility at least exists.)

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

After this change, clang spends ~200ms parsing Attrs.inc instead of
~560ms. A large part of the cost was from the StringSwitch
instantiations, but this is a good way to avoid similar problems in the
future.

Reviewed By: aaron.ballman, rjmccall

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

Detects and fixes suspicious code like: `#include "foo.cpp"`.

Inspired by: https://twitter.com/lefticus/status/1228458240364687360?s=20

https://reviews.llvm.org/D74669

This patch is the callee side counterpart for https://reviews.llvm.org/D73209.
It removes the fatal error when we pass more formal arguments than available
registers.

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

All paths dereference the ClassDecl pointer, so use a cast<> instead of dyn_cast<>, assert that its not null and remove the remaining null tests.

Since D75537 the test suite clears all settings before a test. This caused
two tests to fail:
    lldb-api :: functionalities/inline-stepping/TestInlineStepping.py
    lldb-api :: lang/cpp/std-function-step-into-callable/TestStdFunctionStepIntoCallable.py
The reason for that is that OptionValueRegex::Clear was setting the regex
to empty instead of the default value that was passed initially. This caused
that the target.process.thread.step-avoid-regexp setting which is used in the
tests was set to "" instead of "^std::".

This patch is just a quick fix that sets the regex back to the original value
to make the tests pass.

In total these 3 setting values have changed with D75537 and also need to be
fixed (even though they don't seem to break any tests).
  target.process.thread.step-avoid-regexp (regex) -> from '^std::' to empty string
  platform.module-cache-directory (file) -> from "~/.lldb/module_cache" to empty string
  script-lang (enum) -> from 'default' to 'python'

-M output can be useful when diagnosing an "error: output file too large" problem (emitted in openFile()).

I just ran into such a situation where I had to debug an erronerous
Linux kernel linker script. It tried to create a file larger than
INT64_MAX bytes.

This patch could have helped https://bugs.llvm.org/show_bug.cgi?id=44715 as well.

Reviewed By: grimar

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

Use castAs as we know the cast should succeed (and castAs will assert if it doesn't) and we're dereferencing it directly in the getThisType/getThisObjectType calls.