Blend Insertion + Element Rotation pattern similar to Issue #53124

LLVM Dialect Constant Op translations assume that if the attribute is a
vector, it's a fixed length one, generating an invalid translation for
constant scalable vector initializations.

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

This test case captures the current state of support for printing branch
targets.

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

This makes the def-use relationship between VPCanonicalIVPHIRecipe and
VPWidenCanonicalIVRecipe explicit. Needed for D117140.

[MIPS] Mips16DAGToDAGISel::selectAddr - Use cast<> instead of dyn_cast<> to avoid dereference of nullptr

The pointer is always dereferenced immediately below, so assert the cast is correct instead of returning nullptr

Since 26c6a3e7, LLVM's inliner will "upgrade" the caller's stack protector
attribute based on the callee. This lead to surprising results with Clang's
no_stack_protector attribute added in 4fbf84c1 (D46300). Consider the
following code compiled with clang -fstack-protector-strong -Os
(https://godbolt.org/z/7s3rW7a1q).

  extern void h(int* p);

  inline __attribute__((always_inline)) int g() {
    return 0;
  }

  int __attribute__((__no_stack_protector__)) f() {
    int a[1];
    h(a);
    return g();
  }

LLVM will inline g() into f(), and f() would get a stack protector, against the
users explicit wishes, potentially breaking the program e.g. if h() changes the
value of the stack cookie. That's a miscompile.

More recently, bc044a88 (D91816) addressed this problem by preventing
inlining when the stack protector is disabled in the caller and enabled in the
callee or vice versa. However, the problem remained if the callee is marked
always_inline as in the example above. This affected users, see e.g.
http://crbug.com/1274129 and http://llvm.org/pr52886.

One way to fix this would be to prevent inlining also in the always_inline
case. Despite the name, always_inline does not guarantee inlining, so this
would be legal but potentially surprising to users.

However, I think the better fix is to not enable the stack protector in a
caller based on the callee. The motivation for the old behaviour is unclear, it
seems counter-intuitive, and causes real problems as we've seen.

This commit implements that fix, which means in the example above, g() gets
inlined into f() (also without always_inline), and f() is emitted without stack
protector. I think that matches most developers' expectations, and that's also
what GCC does.

Another effect of this change is that a no_stack_protector function can now be
inlined into a stack protected function, e.g. (https://godbolt.org/z/hafP6W856):

  extern void h(int* p);

  inline int __attribute__((__no_stack_protector__)) __attribute__((always_inline)) g() {
    return 0;
  }

  int f() {
    int a[1];
    h(a);
    return g();
  }

I think that's fine. Such code would be unusual since no_stack_protector is
normally applied to a program entry point which sets up the stack canary. And
even if such code exists, inlining doesn't change the semantics: there is still
no stack cookie setup/check around entry/exit of the g() code region, but there
may be in the surrounding context, as there was before inlining. This also
matches GCC.

See also the discussion at https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94722

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

IR:
- globals (and functions, ifuncs, aliases) can have a partition
- catchret has a `to` before the label
- the sint/int types do not exist
- signext comes after the type
- a variable was missing its type

TableGen:
- The second value after a `#` concatenation is optional
  See e.g. llvm/lib/Target/X86/X86InstrAVX512.td:L3351
- IncludeDirective and PreprocessorDirective were never referenced in
  the grammar
- Add some missing ;
- Parent classes of multiclasses can have generic arguments.
  Reuse the `ParentClassList` that is already used in other places.

MIR:
- liveins only allows physical registers, which start with a $

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

* This is useful when you need to build mixed array from external static/dynamic arrays (e.g. from adaptor during dialect conversion)
* Also, to reduce C++ code in td and generated files

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

If you want to check for all uses of PAC, the SpillsLR argument to
shouldSignReturnAddress should be true instead of false, as that value will be
returned from the function if the other checks fall through.

Reviewed By: miyuki

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

The nounwind and uwtable attributes were just cluttering up the test.
Using regexes to give symbolic names to the attribute lists make the
test more readable.

This is pre-committing parts of D116589.

With https://reviews.llvm.org/D116731 merged, installing Clang, MLIR or
LLVM is no longer required for standalone builds. For consistency sake,
remove "installation" from the build instrucitons.

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

Implement the qXfer:siginfo:read that is used to read the siginfo_t
(extended signal information) for the current thread.  This is currently
implemented on FreeBSD and Linux.

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

We need to check that the load/store type is also the same, as this
is no longer implicitly checked through the pointer type.

Implement support for matching an index from a WebAssembly CALL
instruction. Add test.

Reviewed By: tlively

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

Change FileCheck to accept patterns like "[[[var...]]" and treat the
excess open brackets at the start as literals.

This makes the patterns for matching assembler output with literal
brackets much cleaner. For example an AMDGPU pattern that used to be
written like:

  buffer_store_dwordx2 v{{\[}}[[LO]]:[[HI]]{{\]}}

can now be:

  buffer_store_dwordx2 v[[[LO]]:[[HI]]]

(Even before this patch the final close bracket did not need to be
wrapped in {{}}, but people tended to do it anyway for symmetry.)

This does not introduce any ambiguity since "[[" was always followed by
an identifier or '@' or '#', so "[[[" was always an error.

I've included a few test updates in this patch just for illustration and
testing. There are a couple of hundred tests that could be updated as a
follow up, mostly in test/CodeGen/.

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

Change-Id: Ia6bc6f65cb69734821c911f54a43fe1c673bcca7

When we know the value we're extending is a negative constant then it
makes sense to use SIGN_EXTEND because this may improve code quality in
some cases, particularly when doing a constant splat of an unpacked vector
type. For example, for SVE when splatting the value -1 into all elements
of a vector of type <vscale x 2 x i32> the element type will get promoted
from i32 -> i64. In this case we want the splat value to sign-extend from
(i32 -1) -> (i64 -1), whereas currently it zero-extends from
(i32 -1) -> (i64 0xFFFFFFFF). Sign-extending the constant means we can use
a single mov immediate instruction.

New tests added here:

  CodeGen/AArch64/sve-vector-splat.ll

I believe we see some code quality improvements in these existing
tests too:

  CodeGen/AArch64/dag-numsignbits.ll
  CodeGen/AArch64/reduce-and.ll
  CodeGen/AArch64/unfold-masked-merge-vector-variablemask.ll

The apparent regressions in CodeGen/AArch64/fast-isel-cmp-vec.ll only
occur because the test disables codegen prepare and branch folding.

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

This is a NFC change split off from D116123, as suggested there.
D116123 will remove the last user of CreateSplatIV.

Add a variant of the clspv target that is built using spir64.
This is a pre-requisite to supporting spir64 in clspv which is
required to take advantage of SPV_KHR_physical_storage_buffer which
in turn enables more OpenCL C programs to be compiled with clspv.

https://reviews.llvm.org/D116668

If we are inserting into or extracting from a scalable vector we do
not know the number of elements at runtime, so we can only let the
index wrap for fixed-length vectors.

Tests added here:

  Analysis/CostModel/AArch64/sve-insert-extract.ll

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

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

Do nothing on R_AARCH64_NONE relocation. The relocation is used by BOLT when re-linking the final binary. It is used as a dummy relocation hack in order to stop the RuntimeDyld to skip the allocation of the section.

Reviewed By: lhames

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

In practice we don't expect to see the get.active.lane.mask intrinsic
being used for fixed-width vectors, but we should at least be able
to generate code for it. This patch simply adds some fixed-width tests
to an existing file:

  CodeGen/AArch64/active_lane_mask.ll

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

This patch makes jitlink to report an out of range error when the fixup value out of range

Reviewed By: lhames

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

https://github.com/llvm/llvm-project/issues/27037

Sorry its taken so long to get to this issue! (got it before it hit its 6th birthday!)

```
void operator delete(void *foo)ATTRIB;
```

(void *foo) is incorrectly determined to be a C-Style Cast resulting in the space being removed after the ) and before the attrib, due to the detection of

```
delete (A* )a;
```

The following was previously unaffected

```
void operator new(void *foo) ATTRIB;
```

Fixes #27037

Reviewed By: curdeius, HazardyKnusperkeks

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

Reviewed By: bkramer, tra

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

New values:
- Split Dynamic into Open/Preamble
- Add Background (previously was just Unknown)
- Soon: stdlib index

This requires extending to 16 bits, which fits within the padding of Symbol.
Unfortunately we're also *serializing* SymbolOrigin as a fixed 8 bits.

Stop serializing SymbolOrigin:
- conceptually, the source is whoever indexes or *deserializes* a symbol
- deserialization takes SymbolOrigin as a parameter and stamps it on each sym
- this is a breaking format change

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

C++ member function bodies (including ctor initializers) are first captured
into a buffer and then parsed after the class is complete. (This allows
members to be referenced even if declared later).

When the boundary of the function body cannot be established, its buffer is
discarded and late-parsing never happens (it would surely fail).
For code completion this is the wrong tradeoff: the point of the parse is to
generate completions as a side-effect.
Today, when the ctor body wasn't typed yet there are no init list completions.
With this patch we parse such an init-list if it contains the completion point.

There's one caveat: the parser has to decide where to resume parsing members
after a broken init list. Often the first clear recovery point is *after* the
next member, so that member is missing from completion/signature help etc. e.g.
  struct S {
    S() m  //<- completion here
    int maaa;
    int mbbb;
  }
Here "int maaa;" is treated as part of the init list, so "maaa" is not available
as a completion. Maybe in future indentation can be used to recognize that
this is a separate member, not part of the init list.

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

Identified with readability-redundant-member-init.

Identified with bugprone-argument-comment.

This extends D81784. Sections can be discarded when linking a
relocatable output. Before the patch, LLD did not update the content
of debug sections and only replaced the corresponding relocations with
R_*_NONE, which could break the debug information.

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

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

Somehow this ends up causing an infinite loop in the inliner.

This reverts commit d5be48c6.

Reviewed By: craig.topper

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