Change BasicBlock::removePredecessor to optionally return a vector of
instructions which might be dead. Use this in ConstantFoldTerminator to
delete them if they are dead.

Reapply with a bug fix: don't drop the "!KeepOneInputPHIs" argument when
removePredecessor calls PHINode::removeIncomingValue.

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

Which triggers on valid, but not useful, IR such as a undef mask.

Bugzilla: https://bugs.llvm.org/show_bug.cgi?id=46276

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

...enumerations from TokenKinds.def and use the new macros from TokenKinds.def
to remove the hard-coded lists of traits.

All the information needed to generate these enumerations is already present
in TokenKinds.def. The motivation here is to be able to dump the trait spelling
without hard-coding the list in yet another place.

Note that this change the order of the enumerators in the enumerations (except
that in the TypeTrait enumeration all unary type traits are before all binary
type traits, and all binary type traits are before all n-ary type traits).

Apart from the aforementioned ordering which is relied upon, after this patch
no code in clang or in the various clang tools depend on the specific ordering
of the enumerators.

No functional changes intended.

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

Reviewed By: aaron.ballman

This reverts commit 4494e453.

It caused problems for sanitizer buildbots.

Summary:
This record is constructed by hashing the bytes of the AST block in a similiar
fashion to the SIGNATURE record. This new signature only means anything if the
AST block is fully relocatable, i.e. it does not embed absolute offsets within
the PCM file. This change ensure this does not happen by replacing these offsets
with offsets relative to the nearest relevant subblock of the AST block.

Reviewers: Bigcheese, dexonsmith

Subscribers: dexonsmith, cfe-commits

Tags: #clang

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

Added codegen for scandirectives in simd loop. The codegen transforms
original code:

```
int x = 0;
 #pragma omp simd reduction(inscan, +: x)
for (..) {
  <first part>
  #pragma omp scan inclusive(x)
  <second part>
}
```
into
```
int x = 0;
for (..) {
  int x_priv = 0;
  <first part>
  x = x_priv + x;
  x_priv = x;
  <second part>
}
```
and
```
int x = 0;
 #pragma omp simd reduction(inscan, +: x)
for (..) {
  <first part>
  #pragma omp scan exclusive(x)
  <second part>
}
```
into
```
int x = 0;
for (..) {
  int x_priv = 0;
  <second part>
  int temp = x;
  x = x_priv + x;
  x_priv = temp;
  <first part>
}
```

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

We're only using the D2 iteration value inside the assert (the only component of the loop) - move the entire loop inside the assert by using llvm::all_of.

Demonstrate missing support for OR(X,KSHIFTL(Y,8)) -> KUNPCKBW as well as the existing OR(KSHIFTL(X,8),Y) -> KUNPCKBW test.

Change BasicBlock::removePredecessor to optionally return a vector of
instructions which might be dead. Use this in ConstantFoldTerminator to
delete them if they are dead.

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

...before checking that the default argument is valid with
CheckDefaultArgumentVisitor.

Currently the restrictions on a default argument are checked with the visitor
CheckDefaultArgumentVisitor in ActOnParamDefaultArgument before
performing the conversion to the parameter type in SetParamDefaultArgument.

This was fine before the previous patch but now some valid code post-CWG 2346
is rejected:

void test() {
  const int i2 = 0;
  extern void h2a(int x = i2);     // FIXME: ok, not odr-use
  extern void h2b(int x = i2 + 0); // ok, not odr-use
}

This is because the reference to i2 in h2a has not been marked yet with
NOUR_Constant. i2 is marked NOUR_Constant when the conversion to the parameter
type is done, which is done just after.

The solution is to do the conversion to the parameter type before checking
the restrictions on default arguments with CheckDefaultArgumentVisitor.
This has the side-benefit of improving some diagnostics.

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

Reviewed By: rsmith

The are not needed as Scalar is implicitly constructible from all of
these types (so the compiler will use a combination of a constructor +
move assignment instead), and they make it very easy for implementations
of assignment and construction operations to diverge.

Previously these functions either returned a "changed" flag or a "repeat
instruction" flag, and could also modify an iterator to control which
instruction would be processed next.

Simplify this by always returning a "changed" flag, and handling all of
the "repeat instruction" functionality by modifying the iterator.

No functional change intended except in this case:
// If the source and destination of the memcpy are the same, then zap it.
... where the previous code failed to process the instruction after the
zapped memcpy.

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

[clang] CWG 2082 and 2346: loosen the restrictions on parameters and local variables in default arguments.

This patch implements the resolution of CWG 2082 and CWG 2346.

The resolution of CWG 2082 changed [dcl.fct.default]p7 and p9 to allow
a parameter or local variable to appear in a default argument if not
in a potentially-evaluated expression.

The resolution of CWG 2346 changed [dcl.fct.default]p7 to allow a local
variable to appear in a default argument if not odr-used.

An issue remains after this patch
(see the FIXME in test/CXX/dcl.decl/dcl.meaning/dcl.fct.default/p7.cpp).
This is addressed by the next patch.

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

Reviewed By: rsmith, erichkeane

Before the next patches do the following NFCs:
  - Make it a const visitor; CheckDefaultArgumentVisitor should
    really not modify the visited nodes.

  - clang-format

  - Take a reference to Sema instead of a pointer and pass it
    as the first argument to the constructor. This is for
    consistency with the other similar visitors.

  - Use range for loops when appropriate as per the style guide.

  - Use `const auto *" when appropriate as per the style guide.

Other warnings messages don't have a trailing full stop.

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

- Simplify the salvaging interface and the algorithm in InstCombine

Reviewers: vsk, aprantl, Orlando, jmorse, TWeaver

Reviewed by: Orlando

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

This teaches yaml2obj to allocate file space for a no-bits section
when there is a non-nobits section in the same segment that follows it.

It was discussed in D78005 thread and matches GNU linkers and LLD behavior.

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

AVX512 mask types are often bitcasted to scalar integers for various ops before being bitcast back to be used as a predicate. In many cases we can avoid these KMASK<->GPR transfers and perform equivalent operations on the mask unit.

If the destination mask type is legal, and we can confirm that the scalar op originally came from a mask/vector/float/double type then we should try to avoid the scalar entirely.

This avoids some codegen issues noticed while working on PTEST/MOVMSK improvements.

Partially fixes PR32547 - we don't create a KUNPCK yet, but OR(X,KSHIFTL(Y)) can be handled in a separate patch.

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

Show current codegen baseline before D81548

Summary:
Introduce on-demand parsing of needed ASTs during CTU analysis.
The index-file format is extended, and analyzer-option CTUInvocationList
is added to specify the exact invocations needed to parse the needed
source-files.

Reviewers: martong, balazske, Szelethus, xazax.hun, whisperity

Reviewed By: martong, xazax.hun

Subscribers: gribozavr2, thakis, ASDenysPetrov, ormris, mgorny, whisperity, xazax.hun, baloghadamsoftware, szepet, rnkovacs, a.sidorin, mikhail.ramalho, Szelethus, donat.nagy, dkrupp, Charusso, steakhal, cfe-commits

Tags: #clang

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

Code example in MLIR Linalg doc fixed because it referenced non-existing variables and some parameters were of wrong types.

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

[GlobalISel] fix crash in IRTranslator, MachineIRBuilder when translating @llvm.dbg.value intrinsic and using -debug

Summary:
Fix crash when using -debug caused by the GlobalISel observer trying to print
an incomplete DBG_VALUE instruction. This was caused by the MachineIRBuilder
using buildInstr, which immediately inserts the instruction causing print,
instead of using BuildMI to first build up the instruction and using
insertInstr when finished.

Add RUN-line to existing debug-insts.ll test with -debug flag set to make sure
no crash is happening.

Also fixed a missing %s in the 2nd RUN-line of the same test.

Reviewers: t.p.northover, aditya_nandakumar, aemerson, dsanders, arsenm

Reviewed By: arsenm

Subscribers: wdng, arsenm, rovka, hiraditya, volkan, llvm-commits

Tags: #llvm

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

Reviewers: aprantl, dexonsmith, Bigcheese

Subscribers: arphaman, cfe-commits

Tags: #clang

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

[lldb] Fix a crash in PlatformAppleSimulator::GetCoreSimulatorPath when Xcode developer directory can't be found

Summary:

`PlatformAppleSimulator::GetCoreSimulatorPath` currently checks if
`m_core_simulator_framework_path` wasn't set yet and then tries to calculate its
actual value. However, if `GetXcodeDeveloperDirectory` returns an invalid
FileSpec, `m_core_simulator_framework_path` is never assigned a value which
causes that the `return m_core_simulator_framework_path.getValue();` at the end
of the function will trigger an assert.

This patch just assigns an invalid FileSpec to `m_core_simulator_framework_path`
which seems what the calling code in `PlatformAppleSimulator::LoadCoreSimulator`
expects as an error value.

I assume this can be reproduces on machines that don't have an Xcode
installation, but this patch is mostly based on this backtrace I received from
someone else that tried to run the test suite:

```
Assertion failed: (hasVal), function getValue, file llvm/include/llvm/ADT/Optional.h, line 73.
[...]
3   libsystem_c.dylib             	0x00007fff682a1ac6 __assert_rtn + 314
4   liblldb.11.0.0git.dylib       	0x000000010b835931 PlatformAppleSimulator::GetCoreSimulatorPath() (.cold.1) + 33
5   liblldb.11.0.0git.dylib       	0x0000000107e92f11 PlatformAppleSimulator::GetCoreSimulatorPath() + 369
6   liblldb.11.0.0git.dylib       	0x0000000107e9383e void std::__1::__call_once_proxy<std::__1::tuple<PlatformAppleSimulator::LoadCoreSimulator()::$_1&&> >(void*) + 30
7   libc++.1.dylib                	0x00007fff654d5bea std::__1::__call_once(unsigned long volatile&, void*, void (*)(void*)) + 139
8   liblldb.11.0.0git.dylib       	0x0000000107e92019 PlatformAppleSimulator::LaunchProcess(lldb_private::ProcessLaunchInfo&) + 89
9   liblldb.11.0.0git.dylib       	0x0000000107e92be5 PlatformAppleSimulator::DebugProcess(lldb_private::ProcessLaunchInfo&, lldb_private::Debugger&, lldb_private::Target*, lldb_private::Status&) + 101
10  liblldb.11.0.0git.dylib       	0x0000000107cb044d lldb_private::Target::Launch(lldb_private::ProcessLaunchInfo&, lldb_private::Stream*) + 669
11  liblldb.11.0.0git.dylib       	0x000000010792c9c5 lldb::SBTarget::Launch(lldb::SBLaunchInfo&, lldb::SBError&) + 1109
12  liblldb.11.0.0git.dylib       	0x0000000107a92acd _wrap_SBTarget_Launch(_object*, _object*) + 477
13  org.python.python             	0x000000010681076f PyCFunction_Call + 321
14  org.python.python             	0x000000010689ee12 _PyEval_EvalFrameDefault + 7738
```

Reviewers: JDevlieghere, jasonmolenda

Reviewed By: JDevlieghere

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

Summary: Add RUN lines for pwr8.

By moving target-independent code from
llvm/lib/Target/X86/X86IndirectThunks.cpp
to
llvm/include/llvm/CodeGen/IndirectThunks.h

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

This appears to have been added when In64BitMode was added to a
bunch of instructions that don't have register operands. When an
instruction uses a register the parser will prevent a 64-bit
register from being parsed on a 32-bit target. But with only
memory and immediate operands this doesn't happen.

TEST64ri32 does have a register operand so the issue the predicate
was supposed to fix doesn't apply.

Until we have a real need for computing known bits for scalable
vectors I have simply changed the code to bail out for now and
pretend we know nothing. I've also fixed up some simple callers of
computeKnownBits too.

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

Some processors may speculatively execute the instructions immediately
following RET (returns) and BR (indirect jumps), even though
control flow should change unconditionally at these instructions.
To avoid a potential miss-speculatively executed gadget after these
instructions leaking secrets through side channels, this pass places a
speculation barrier immediately after every RET and BR instruction.

Since these barriers are never on the correct, architectural execution
path, performance overhead of this is expected to be low.

On targets that implement that Armv8.0-SB Speculation Barrier extension,
a single SB instruction is emitted that acts as a speculation barrier.
On other targets, a DSB SYS followed by a ISB is emitted to act as a
speculation barrier.

These speculation barriers are implemented as pseudo instructions to
avoid later passes to analyze them and potentially remove them.

Even though currently LLVM does not produce BRAA/BRAB/BRAAZ/BRABZ
instructions, these are also mitigated by the pass and tested through a
MIR test.

The mitigation is off by default and can be enabled by the
harden-sls-retbr subtarget feature.

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

Outline chunks of code which don't need a save/restore mechanism of the
link register.

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

The "if (S.getLangOpts().CUDA && Cand1.Function && Cand2.Function) {"
part is known to be problematic but the root cause isn't clear yet.