Revert "[clangd] Reapply b60896fa Fall back to selecting token-before-cursor if token-after-cursor fails."

This reverts commit a0ff8cd6.
Buildbot failures I can't chase further tonight.

Now that the machine verifier will check for cases of register/immediate
MachineOperands and their correspondence to the MC instruction descriptor,
this patch adds the operand types to the descriptors where they were
previously missing. All MCOI::OPERAND_UNKNOWN operand types have been handled
to get a known type, except for G_... (global isel) instructions.

Review: Ulrich Weigand
https://reviews.llvm.org/D71494

Summary:
llvm-cxxfilt wasn't correctly demangle COFF import thunk in those two
cases before:
* demangle in split mode (multiple words from commandline)
* the import thunk prefix was added no matter the later part of the
string can be demangled or not
Now llvm-cxxfilt should handle both case correctly.

Reviewers: compnerd, erik.pilkington, jhenderson

Reviewed By: jhenderson

Subscribers: jkorous, dexonsmith, ributzka, llvm-commits

Tags: #llvm

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

Summary:

Follow-on to D66428 and D71193, to build the TLI per-function so
that -fno-builtin* handling can be migrated to use function attributes.
See discussion on D61634 for background. This is an enabler for fixing
handling of these options for LTO, for example.

With D71193, the -fno-builtin* flags are converted to function
attributes, so we can now set this information per-function on the TLI.

In this patch, the TLI constructor is changed to take a Function, which
can be used to override the available builtins. The TLI is augmented
with an array that can be used to specify which builtins are not
available for the corresponding function. The available function checks
are changed to consult this override before checking the underlying
module level baseline TLII. New code is added to set this override
array based on the attributes.

I also removed the code that sets availability in the TLII in clang from
the options, which is no longer needed.

I removed a per-Triple caching of TLII objects in the analysis object,
as it is based on the Module's Triple which is the same for all
functions in any case. Is there a case where we would be compiling
multiple Modules with different Triples in one compilation?

Finally, I have changed the legacy analysis wrapper to create and use
the new PM analysis class (TargetLibraryAnalysis) in getTLI. This is
consistent with the behavior of getTTI for the legacy
TargetTransformInfo analysis. This change means that getTLI now creates
a new TLI on each call (although that should be very cheap as we cache
the module level TLII, and computing the per-function
attribute based availability should also be reasonably efficient).
I measured the compile time for a large C++ file with tens of thousands
of functions and as expected there was no increase.

Reviewers: chandlerc, hfinkel, gchatelet

Subscribers: mehdi_amini, dexonsmith, llvm-commits

Tags: #llvm

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

Summary:
Add unwinding support for 64-bit RISC-V.

This is from the FreeBSD implementation with the following minor
changes:

- Renamed and renumbered DWARF registers to match the RISC-V ABI [1]
- Use the ABI mneumonics in getRegisterName() instead of the exact
   register names
- Include checks for __riscv_xlen == 64 to facilitate adding the 32-bit
   ABI in the future.

[1] https://github.com/riscv/riscv-elf-psabi-doc/blob/master/riscv-elf.md

Patch by Mitchell Horne (mhorne)

Reviewers: lenary, luismarques, compnerd, phosek

Reviewed By: lenary, luismarques

Subscribers: arichardson, sameer.abuasal, abidh, asb, aprantl, krytarowski, simoncook, kito-cheng, christof, shiva0217, rogfer01, rkruppe, PkmX, psnobl, benna, lenary, s.egerton, luismarques, emaste, cfe-commits

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

If a function requires optnone to trigger a crash, it must also have noline,
otherwise it will fail a verifier check.

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

Revert "Revert "[libomptarget] Move resource id functions into target specific code, implement for amdgcn""

Summary:
This reverts commit dd8a7fcd.

Alexey reports undefined symbols for the new inline functions defined in target_impl.h
This does not reproduce for me for nvptx, or amdgcn, under release or debug builds.

I believe the patch is fine, based on:
 - the semantics of an inline function in C++ (the cuda INLINE functions end
   up as linkonce_odr in IR), which are only legal to drop if they have no uses
 - the code generated from a debug build of clang 9 does not show these undef symbols
 - the tests pass
 - the code is trivial

To progress from here I either need:
 - A tie break - someone to play the role of CI in determining whether the patch works
 - Alexey to provide sufficient information about his build for me to reproduce the failure
 - Alexey to debug why the symbols are disappearing for him and report back

Reviewers: ABataev, jdoerfert, grokos

Subscribers: jvesely, openmp-commits

Tags: #openmp

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

Check if the TargetStreamer can be accessed.

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

Test latency with explicit register dependency, without and with
forbidden registers.

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

According to OpenMP 5.0, if clause can be used in for simd directive. If
condition in the if clause if false, the non-vectorized version of the
loop must be executed.

As brought up in D71467, a group of floating point builtins
automatically promoted floats to doubles because they used the variadic
builtin tag to support an overload set. The result is that the
parameters were treated as a variadic pack, which always promots
float->double.

This resulted in the wrong answer being given in cases with certain
values of NaN.

Handle -march=native in systemz::getSystemZTargetCPU, similar to
how this is done on other platforms.  Also change the return type
to std::string instead of const char *.

[clangd] Reapply b60896fa Fall back to selecting token-before-cursor if token-after-cursor fails.

This reverts commit 8f876d51.

Revert "[clangd] Reapply b60896fa Fall back to selecting token-before-cursor if token-after-cursor fails."

This reverts commit 2500a8d5.

[clangd] Reapply b60896fa Fall back to selecting token-before-cursor if token-after-cursor fails.

This reverts commit f0604e73
The issue with movability of Tweak::Selection was addressed in 7dc388bd

This reverts commit d6417f55. The tests
depend on builtin headers, which is not intentionally supported in
clangd tests; these tests are broken in some build environments.

This reverts commit 181ab91e.

Summary:
Reland after fixing a bug that allowed outlining of SP modifying instructions
that invalidated return address signing.

During AArch64 frame lowering instructions to enable return address
signing are inserted into functions if needed. Functions generated during
machine outlining don't run through target frame lowering and hence are
missing such instructions.

This patch introduces the following changes:

1. If not all functions that potentially participate in function outlining agree
   on their return address signing scope and their return address signing key,
   outlining is disabled for these functions.
2. If not all functions that potentially participate in function outlining agree
   on their support for v8.3A features, outlining is disabled for these
   functions.
3. If an outlining candidate would outline instructions that modify sp in a way
   that invalidates return address signing, outlining is disabled for that
   particular candidate.
4. If all candidate functions agree on the signing scope, signing key and their
   support for v8.3 features, the outlined function behaves as if it had the
   same scope and key attributes and as if it would provide the same v8.3A
   support as the original functions.

Reviewers: ostannard, paquette

Reviewed By: ostannard

Subscribers: kristof.beyls, hiraditya, llvm-commits

Tags: #llvm

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

The is the best method we have at the moment for attach-style tests.

Summary: This is a follow up on D71137 properly setting up the AsmTargetStreamer prior to AsmParser::Run call.

Reviewers: courbet, mstojanovic

Subscribers: tschuett, mikhail.ramalho, llvm-commits, petarj, atanasyan

Tags: #llvm

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

Summary:
This patch introduces a set of functions to enable deprecation of IRBuilder functions without breaking out of tree clients.
Functions will be deprecated one by one and as in tree code is cleaned up.

This is patch is part of a series to introduce an Alignment type.
See this thread for context: http://lists.llvm.org/pipermail/llvm-dev/2019-July/133851.html
See this patch for the introduction of the type: https://reviews.llvm.org/D64790

Reviewers: courbet

Subscribers: arsenm, jvesely, nhaehnle, hiraditya, llvm-commits

Tags: #llvm

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

Summary:
The following intrinsics for binary narrowing add and sub operations are
added:
  * @llvm.aarch64.sve.addhnb
  * @llvm.aarch64.sve.addhnt
  * @llvm.aarch64.sve.raddhnb
  * @llvm.aarch64.sve.raddhnt
  * @llvm.aarch64.sve.subhnb
  * @llvm.aarch64.sve.subhnt
  * @llvm.aarch64.sve.rsubhnb
  * @llvm.aarch64.sve.rsubhnt

Reviewers: sdesmalen, rengolin, efriedma

Reviewed By: sdesmalen, efriedma

Subscribers: tschuett, kristof.beyls, hiraditya, llvm-commits

Tags: #llvm

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

The emission of stack maps in AArch64 binaries has been disabled for all
binary formats except Mach-O since rL206610, probably mistakenly, as far
as I can tell. This patch reverts this to its intended state.

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

Patch by Loic Ottet.

Summary:
This patch adds the following SVE intrinsics for scatter stores:
* 64-bit offsets:
  * @llvm.aarch64.sve.st1.scatter (unscaled)
  * @llvm.aarch64.sve.st1.scatter.index (scaled)
* 32-bit unscaled offsets:
  * @llvm.aarch64.sve.st1.scatter.uxtw (zero-extended offset)
  * @llvm.aarch64.sve.st1.scatter.sxtw (sign-extended-offset)
* 32-bit scaled offsets:
  * @llvm.aarch64.sve.st1.scatter.uxtw.index (zero-extended offset)
  * @llvm.aarch64.sve.st1.scatter.sxtw.index (sign-extended offset)
* vector base + immediate:
  * @llvm.aarch64.sve.st1.scatter.imm

Reviewers: rengolin, efriedma, sdesmalen

Reviewed By: efriedma, sdesmalen

Subscribers: kmclaughlin, eli.friedman, tschuett, kristof.beyls, hiraditya, rkruppe, psnobl, llvm-commits

Tags: #llvm

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

Summary:
This commit adds basic tests for these update script to validate that
they still work as expected. In the future we could extend these tests
whenever new features are added to avoid introducing regressions.

Reviewers: xbolva00, MaskRay, jdoerfert

Reviewed By: jdoerfert

Subscribers: llvm-commits

Tags: #llvm

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

The overloads that don't take a CompilerType serve no purpose as we
always have a CompilerType in the scope where we call them. Instead
just call the overload that takes a CompilerType and delete the
now unused other overloaded methods.

Summary:
These types were handled in some places, but not others. This resulted
in (for example) not being able to display members of structs whose
types were defined using these constructs.

Using getLocallyUnqualifiedSingleStepDesugaredType for these types is
not fully equivalent, as it will only desugar them if the types are not
instantiation-dependent, whereas previously we did that unconditionally.

It's not clear to me which behavior is correct here, but the test suite
does not seem to care either way.

Reviewers: teemperor, shafik

Subscribers: lldb-commits

Tags: #lldb

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

Summary:
In commit d60f34c2 (llvm-svn 317128,
PR35113) MergeBlockIntoPredecessor was changed into
discarding some dbg.value intrinsics referring to
PHI values, post-splice due to loop rotation.

That elimination of dbg.value intrinsics did not
consider which dbg.value to keep depending on the
context (e.g. if the variable is changing its value
several times inside the basic block).

In the past that hasn't been such a big problem since
CodeGenPrepare::placeDbgValues has moved the dbg.value
to be next to the PHI node anyway. But after commit
00e23889 CodeGenPrepare isn't doing that
any longer, so we need to be more careful when avoiding
duplicate dbg.value intrinsics in MergeBlockIntoPredecessor.

This patch replaces the code that tried to avoid duplicate
dbg.values by using the RemoveRedundantDbgInstrs helper.

Reviewers: aprantl, jmorse, vsk

Reviewed By: aprantl, vsk

Subscribers: jholewinski, hiraditya, llvm-commits

Tags: #llvm

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

Summary:
In commit d60f34c2 (llvm-svn 317128,
PR35113) MergeBlockIntoPredecessor was changed into
discarding some dbg.value intrinsics referring to
PHI values, post-splice due to loop rotation.

That elimination of dbg.value intrinsics does not
consider which dbg.value to keep based on the context.
Such as always keeping the one that comes first textually,
or the need to keep several of them in case the variable
is changing it's value several times inside the basic block.

In the past that hasn't been such a big problem since
CodeGenPrepare::placeDbgValues has moved the dbg.value
to be next to the PHI node anyway. But after commit
00e23889 CodeGenPrepare isn't doing that
any longer, so we need to be more careful when avoiding
duplicate dbg.value intrinsics in MergeBlockIntoPredecessor.

This patch is just a pre commit of the test case.

Subscribers: llvm-commits

Tags: #llvm

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

Summary:
Add a RemoveRedundantDbgInstrs to BasicBlockUtils with the
goal to remove redundant dbg intrinsics from a basic block.

This can be useful after various transforms, as it might
be simpler to do a filtering of dbg intrinsics after the
transform than during the transform.
One primary use case would be to replace a too aggressive
removal done by MergeBlockIntoPredecessor, seen at loop
rotate (not done in this patch).

The elimination algorithm currently focuses on dbg.value
intrinsics and is doing two iterations over the BB.

First we iterate backward starting at the last instruction
in the BB. Whenever a consecutive sequence of dbg.value
instructions are found we keep the last dbg.value for
each variable found (variable fragments are identified
using the  {DILocalVariable, FragmentInfo, inlinedAt}
triple as given by the DebugVariable helper class).

Next we iterate forward starting at the first instruction
in the BB. Whenever we find a dbg.value describing a
DebugVariable (identified by {DILocalVariable, inlinedAt})
we save the {DIValue, DIExpression} that describes that
variables value. But if the variable already was mapped
to the same {DIValue, DIExpression} pair we instead drop
the second dbg.value.

To ease the process of making lit tests for this utility a
new pass is introduced called RedundantDbgInstElimination.
It can be executed by opt using -redundant-dbg-inst-elim.

Reviewers: aprantl, jmorse, vsk

Subscribers: hiraditya, llvm-commits

Tags: #llvm

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