llvm-svn: 342148

I don't have a test case for this, but it's motivated by
the discussion in D51964, and I've added TODO comments for
the better fix - move simplifications into instsimplify
because that's more efficient and reduces risk of infinite
loops in instcombine caused by transforms trying to do the
opposite folds.

In this case, we know that the transform that tries to move
'not' through min/max can be fooled by the multiple uses
of a value in another min/max, so try to squash the 
foldSPFofSPF() patterns first.

llvm-svn: 342147

If --just-syms is used the mapping symbols from the ELF file will be
absolute symbols with no section. The code to process mapping symbols in
--fix-cortex-a53-843419 assumes that these symbols have a defining section
so a crash will result when --just-syms is used. The simple fix is to not
process the symbol when it doesn't have a section.

Fixes PR37971

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

llvm-svn: 342146

Reviewers: ruiu, pcc

Reviewed By: ruiu

Subscribers: llvm-commits

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

llvm-svn: 342145

Summary: It should be "wasm-ld", not "wasm-lld".

Reviewers: ruiu

Reviewed By: ruiu

Subscribers: aheejin, sunfish, llvm-commits

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

llvm-svn: 342144

%s/MaxCandidateCount/Limit/g after rL342138.

llvm-svn: 342143

After landing r341457, we started seeing a failure on the swift-lldb
bots. The change was correct and pretty straightforward, a DW_OP_constu
was replaced with DW_OP_lit23, the value remaining identical.

  0x000000f4: DW_TAG_variable
		DW_AT_location    (0x00000000
		  [0x0000000100000a51,  0x0000000100000d47): DW_OP_lit23, DW_OP_stack_value)
		DW_AT_name        ("number")

However, this broke LLDB.

  (Int) number = <extracting data from value failed>

The value was read correctly, but apparently the value's type was different.
When reading a constu it was reading a uint64 (m_type = e_ulonglong) while for
the literal, it got a signed int (m_type = e_sint). This change makes sure we
read the value as an unsigned.

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

llvm-svn: 342142

We previously only allowed truncs as sinks, but now allow them as
sources too. We do this by checking that the result type is the
narrow type that we're trying to optimise for.

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

llvm-svn: 342141

Part of FixConsts wrongly assumes either a 8- or 16-bit constant
which can result in the wrong constants being generated during
promotion.

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

llvm-svn: 342140

Summary:
Before:
main.o: main.c ../include/lib\test.h

After:
main.o: main.c ../include/lib/test.h

Fixes PR38877

Reviewers: zturner

Subscribers: xbolva00, cfe-commits

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

llvm-svn: 342139

As discussed during D51860 review, it is better to use `llvm::Optional`
here as it has clear semantics which reflect intended behavior.

Reviewed By: sammccall

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

llvm-svn: 342138

After `FuzzyFindRequest` JSON (de)serialization was introduced, it
should replace ad-hoc fuzzy-find request parsing implemented in the
IndexBenchmark driver.

Reviewed By: ilya-biryukov

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

llvm-svn: 342137

In r319995, we fixed the line table format to version 2 on Darwin
because dsymutil didn't yet understand the new format which caused test
failures for the LLDB bots. This has been resolved in the meantime so
there's no reason to keep this limitation.

rdar://problem/35968332

llvm-svn: 342136

Summary:
The cancelable scopes are managed by JSONRPCDispatcher so that all Handlers
run in cancelable contexts.
(Previously ClangdServer did this, for code completion only).

Cancellation request processing is therefore also in JSONRPCDispatcher.
(Previously it was in ClangdLSPServer).

This doesn't actually make any new commands *respect* cancellation - they'd
need to check isCancelled() and bail out. But it opens the door to doing
this incrementally, and putting such logic in common machinery like TUScheduler.

I also rewrote the ClangdServer class/threading comments because I wanted to
add to it and I got carried away.

Reviewers: ilya-biryukov, kadircet

Subscribers: ioeric, MaskRay, jkorous, arphaman, cfe-commits

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

llvm-svn: 342135

Summary:
The wording implies global index support, which is confusing.
As most users shouldn't care about this flag, also make it hidden to avoid
further confusion.

Reviewers: sammccall, ilya-biryukov

Subscribers: MaskRay, jkorous, arphaman, kadircet, cfe-commits

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

llvm-svn: 342134

If an argument was passed on the stack, this
was using the default alignment.

I'm not sure there's an observable change from this. This
was observable due to bugs in expansion of unaligned
loads and stores, but since that is fixed I don't think
this matters much.

llvm-svn: 342133

This was trying to scalarizing a scalar FP type,
resulting in an assert.

Fixes unaligned f64 stack stores for AMDGPU.

llvm-svn: 342132

llvm-svn: 342131

Summary:
Task is no longer exposed:
 - task cancellation is hidden as a std::function
 - task creation returns the new context directly
 - checking is via free function only, with no way to avoid the context lookup
The implementation is essentially the same, but a bit terser as it's hidden.

isCancelled() is now safe to use outside any task (it returns false).
This will leave us free to sprinkle cancellation in e.g. TUScheduler without
needing elaborate test setup, and lets callers that don't cancel "just work".

Updated the docs to describe the new expected use pattern.
One thing I noticed: there's nothing async-specific about the cancellation.
Async tasks can be cancelled from any thread (typically the one that created
them), sync tasks can be cancelled from any *other* thread in the same way.
So the docs now refer to "long-running" tasks instead of async ones.

Updated usage in code complete, without any structural changes.
I didn't update all the names of the helpers in ClangdLSPServer (these will
likely be moved to JSONRPCDispatcher anyway).

Reviewers: ilya-biryukov, kadircet

Subscribers: ioeric, MaskRay, jkorous, arphaman, jfb, cfe-commits

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

llvm-svn: 342130

Many editors provide extensions and plugins with LSP Client
functionality. Many of these are known to work with Clangd, this patch
points users to the relevant resources for better experience.

Reviewed By: ioeric, ilya-biryukov

Differential Revision

llvm-svn: 342129

llvm-svn: 342128

The Technical Reference Manuals for these two CPUs state that branching
to an unaligned 32-bit instruction incurs an extra pipeline reload
penalty. That's bad.

This also enables the optimization at -Os since it costs on average one
byte per loop in return for 1 cycle per iteration, which is pretty good
going.

llvm-svn: 342127

Functions generated by clang and included in the .init_array section (such as
static constructors) do not follow the usual code path for adding
target-specific function attributes, so we have to add the return address
signing attribute here too, as is currently done for the sanitisers.

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

llvm-svn: 342126

Fix MSVC "illegal conversion; more than one user-defined conversion has been implicitly applied" warning. NFCI.

llvm-svn: 342125

`AND( AND( Child ) ... )` -> `AND( Child ... )`
`AND( OR( Child ) ... )` -> `AND( Child ... )`

This simple optimization results in 5-6% performance improvement in the
benchmark with 2000 serialized `FuzzyFindRequest`s.

Reviewed By: ilya-biryukov

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

llvm-svn: 342124

Summary:
Given that the indexer binary is put directly into ./bin directory
when built, 'clangd-' prefix seems to provide better context to the
reader than 'global-'.

The new name is also shorter and easier to type.

Reviewers: ioeric, sammccall, kadircet

Reviewed By: ioeric, sammccall

Subscribers: kbobyrev, ilya-biryukov, mgorny, MaskRay, jkorous, arphaman, cfe-commits

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

llvm-svn: 342123

Summary:
This change has a number of fixes for FDR mode in compiler-rt along with
changes to the tooling handling the traces in llvm.

In the runtime, we do the following:

- Advance the "last record" pointer appropriately when writing the
  custom event data in the log.

- Add XRAY_NEVER_INSTRUMENT in the rewinding routine.

- When collecting the argument of functions appropriately marked, we
  should not attempt to rewind them (and reset the counts of functions
  that can be re-wound).

In the tooling, we do the following:

- Remove the state logic in BlockIndexer and instead rely on the
  presence/absence of records to indicate blocks.

- Move the verifier into a loop associated with each block.

Reviewers: mboerger, eizan

Subscribers: llvm-commits, hiraditya

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

llvm-svn: 342122

Summary:
Similar to what we did in D50681, we now stop manually byte counting here
in the SourceManager.

Reviewers: #lldb, JDevlieghere

Reviewed By: #lldb, JDevlieghere

Subscribers: JDevlieghere, abidh, lldb-commits

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

llvm-svn: 342121

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

    Reviewers: rampitec

llvm-svn: 342120

This implements suggesting alternative mnemonics when an invalid one is
specified. For example `addru $9, $6, 17767` leads to the following
error message:

error: unknown instruction, did you mean: add, addiu, addu, maddu?

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

llvm-svn: 342119

llvm-svn: 342118

Summary:
The snippet-generation part goes to the SnippetGenerator class.

This will allow benchmarking arbitrary code (see PR38437).

Reviewers: gchatelet

Subscribers: mgorny, tschuett, llvm-commits

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

llvm-svn: 342117

PR38854

Differential Revision: http://reviews.llvm.org/D51719

llvm-svn: 342116

    [AMDGPU] Preliminary patch for divergence driven instruction selection. Load offset inlining pattern changed.

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

    Reviewers: rampitec

llvm-svn: 342115

Summary:
Previously we type legalized v2i32 div/rem by promoting to v2i64. But we don't support div/rem of vectors so op legalization would then scalarize it using i64 scalar ops since it doesn't know about the original promotion. 64-bit scalar divides on Intel hardware are known to be slow and in 32-bit mode they require a libcall.

This patch switches type legalization to do the scalarizing itself using i32.

It looks like the division by power of 2 optimization is still kicking in and leaving the code as a vector. The division by other constant optimization doesn't kick in pre type legalization since it ignores illegal types. And previously, after type legalization we scalarized the v2i64 since we don't have v2i64 MULHS/MULHU support.

Another option might be to widen v2i32 to v4i32 so we could do division by constant optimizations, but we'd have to be careful to only do that for constant divisors or we risk scalaring to 4 scalar divides.

Reviewers: RKSimon, spatel

Reviewed By: spatel

Subscribers: llvm-commits

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

llvm-svn: 342114

llvm-svn: 342111

The `IMAGE_REL_ARM_BRANCH20T` applies only to a `b.w` instruction.  A
thumb-2 `bl` should be relocated using a `IMAGE_REL_ARM_BRANCH24T`.
Correct the relocation that we emit in such a case.

Resolves PR38620!  Based on the patch by Jordan Rhee!

llvm-svn: 342109

llvm-svn: 342108

llvm-svn: 342107

llvm-svn: 342106