Summary:
Thanks to probinson for noticing this in his review of D41956.

Now that we have repository callsigns set in all the other
LLVM/Clang projects' .arcconfig files, we can set the top-level
LLVM .arcconfig repository callsign to "L".

This will correctly Cc: llvm-commits@ on all review requests
sent out from the LLVM repo directory, using Herald rule H270.

Reviewers: klimek, sammccall

Reviewed By: sammccall

Subscribers: llvm-commits, probinson, asb

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

llvm-svn: 322374

I'm not even sure if this transform is ever worth it, but this at least
stops the bleeding.

llvm-svn: 322373

Part of the fix for https://bugs.llvm.org/show_bug.cgi?id=35812.
This patch ensures that the compare operand for the atomic compare and swap
is properly zero-extended to 32 bits if applicable.
A follow-up commit will fix the extension for the SETCC node generated when
expanding an ATOMIC_CMP_SWAP_WITH_SUCCESS. That will complete the bug fix.

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

llvm-svn: 322372

Summary:
Enumerating the contents of a namespace or global scope will omit any
decls that aren't already loaded, instead of deserializing them from the
PCH.

This allows a fast hybrid code completion where symbols from headers are
provided by an external index. (Sema already exposes the information
needed to do a reasonabl job of filtering them).
Clangd plans to implement this hybrid.

This option is just a hint - callers still need to postfilter results if
they want to *avoid* completing decls outside the main file.

Reviewers: bkramer, ilya-biryukov

Subscribers: cfe-commits

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

llvm-svn: 322371

Summary:
For some cases, GoToDefinition will navigate to the forward class
declaration, we should always navigate to the class definition.

Reviewers: sammccall

Reviewed By: sammccall

Subscribers: klimek, ilya-biryukov, cfe-commits

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

llvm-svn: 322370

This reverts commit r322124 since some tests were broken by that patch.
Will recommmit once the patch is fixed.

llvm-svn: 322369

We don't yet match all the patterns involving G_FMA. Add tests for some
of the ones that we do match.

llvm-svn: 322368

llvm-svn: 322367

For hard float with VFP4, it is legal. Otherwise, we use libcalls.

This needs a bit of support in the LegalizerHelper for soft float
because we didn't handle G_FMA libcalls yet. The support is trivial, as
the only difference between G_FMA and other libcalls that we already
handle is that it has 3 input operands rather than just 2.

llvm-svn: 322366

The compiler could not find the conversion from
unique_ptr<WritableMemoryBuffer> to unique_ptr<MemoryBuffer>. This will
hopefully help it along.

llvm-svn: 322365

Currently, IRC contains `Begin` and `Step` as SCEVs and `End` as value.
Aside from that, `End` can also be `nullptr` which can be later conditionally
converted into a non-null SCEV.

To make this logic more transparent, this patch makes `End` a SCEV and
calculates it early, so that it is never a null.

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

llvm-svn: 322364

This avoids the need for const_casting the memory buffer contents in
order to write to it.

NFCI.

llvm-svn: 322363

Previously we checked (HeaderSize == 0) to find out if
PltSection section is IPLT or PLT. Some targets does not set
HeaderSize though. For example PPC64 has no lazy binding implemented
and does not set PltHeaderSize constant.

Because of that using of both IPLT and PLT relocations worked
incorrectly there (testcase is provided).

Patch fixes the issue.

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

llvm-svn: 322362

This patch teaches the Arm back-end to generate the SMMULR, SMMLAR and SMMLSR
instructions from equivalent IR patterns.

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

llvm-svn: 322361

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

llvm-svn: 322360

AT> lma_region expression allows to specify the memory region
for section load address.

Should fix PR35684.

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

llvm-svn: 322359

Re-enable Select after a couple of fixes.

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

llvm-svn: 322358

This is a fix for PR35884.

When we want to delete dead loop we must clean uses in unreachable blocks
otherwise we'll get an assert during deletion of instructions from the loop.

Reviewers: anna, davide
Reviewed By: anna
Subscribers: llvm-commits, lebedev.ri
Differential Revision: https://reviews.llvm.org/D41943

llvm-svn: 322357

[X86] Don't allow lods/stos/scas/cmps/movs to be parsed without a suffix and only memory operand in at&t syntax.

Without a register with a size being mentioned the instruction is ambiguous in at&t syntax. With Intel syntax the memory operation caries a size that can be used to disambiguate.

llvm-svn: 322356

llvm-svn: 322355

While the suffix isn't required to disambiguate the instructions, it is required in order to parse the instructions when the suffix is specified in order to match the GNU assembler.

llvm-svn: 322354

llvm-svn: 322353

llvm-svn: 322352

As mentioned by EricWF in revision D41830

llvm-svn: 322351

In certain combinations of templated classes and friend functions, the body
of friend functions does not get propagated along with function signature.
Exclude friend functions for hashing to avoid this case.

llvm-svn: 322350

Summary:
Currently LLVM has no way to support configuring for IDE's like CLion. Like XCode and MSVC's IDE, CLion needs to see all of the headers and tablegen files in order to properly parse the sources.

This patch adds an `LLVM_ENABLE_IDE` option which can be used to configure for IDE's in general. It is used by `LLVMProcessSources.cmake` to determine if the extra source files should be added to the target.

Unfortunately because of the low level of `LLVMProcessSources.cmake`, I'm not sure where the `LLVM_ENABLE_IDE` option should live. I choose `HandleLLVMOptions.cmake` so that out-of-tree Clang builds would correctly configure the option by default.



Reviewers: beanz, mgorny, lebedev.ri

Reviewed By: beanz

Subscribers: llvm-commits

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

llvm-svn: 322349

RemoveInvalidLocations was clearing out the m_locations in the
breakpoint by hand, and it wasn't also clearing the locations from
the address->location map, which confused us when we went to update
breakpoint locations.  

I also made Breakpoint::ModulesChanged check the Location's Section
to make sure it hadn't been deleted.  This shouldn't strictly be necessary,
but if the DynamicLoaderPlugin doesn't do it's job right (I'm looking at
you new Darwin DynamicLoader...) then it can end up leaving stale locations
on rerun.  It doesn't hurt to clean them up here as a backstop.

<rdar://problem/36134350>

llvm-svn: 322348

llvm-svn: 322347

llvm-svn: 322346

Summary:

This change allows checking for ISA extensions in print methods.

Reviewers: asb, niosHD

Reviewed By: asb, niosHD

Subscribers: llvm-commits, niosHD, asb, rbar, johnrusso, simoncook, jordy.potman.lists, sabuasal

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

llvm-svn: 322345

llvm-svn: 322344

The spec doesn't allow this.

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

llvm-svn: 322343

llvm-svn: 322342

llvm-svn: 322341

This test stresses expression evaluation support for template functions.
Currently the support is rudimentary, and running this test causes assertion
failures in clang. This test cannot be XFAIL'ed because the test harness
treats assertion failures as unexpected events. For now, the test must be
skipped.

llvm-svn: 322340

been specified yet (either by the user, or by one of the lldb
extensions like qHostInfo or qProcessInfo), and the target.xml
includes a <architecture> tag specifying x86_64, set the architecture
appropriately.

I'm not sure what we can expect to see in the <architecture> tag, so
I'm only doing this for x86_64 right now where I've seen "i386:x86_64"
used.  I've seen a target.xml from a jtag board that sends just "arm"
because it doesn't know more specifically what type of board it is
connected to...  

<rdar://problem/29908970> 

llvm-svn: 322339

This is failing on the bot but not locally.  Maybe
the error message will tell us why.

llvm-svn: 322338

llvm-svn: 322337

ExecutionSession will represent a running JIT program.

VModuleKey is a unique key assigned to each module added as part of
an ExecutionSession. The Layer concept will be updated in future to
require a VModuleKey when a module is added.

llvm-svn: 322336

Summary:
This revision causes Skylake (and apparently, only Skylake) codegen to fail in
certain cases. Details: https://bugs.llvm.org/show_bug.cgi?id=35918

Subscribers: sanjoy, llvm-commits

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

llvm-svn: 322335