bcopy is still widely used mainly for network apps. Sadly, LLVM has no optimizations for bcopy, but there are some for memmove. 
Since bcopy == memmove, it is profitable to transform bcopy to memmove and use current optimizations for memmove for free here.

llvm-svn: 373537

If the vselect result type needs to be split, it will try to
also try to split the condition if it happens to be a setcc.

With avx512 where k-registers are legal, its probably better
to just use a kshift to split the mask register.

llvm-svn: 373536

[LegalizeTypes] Check for already split condition before calilng SplitVecRes_SETCC in SplitRes_SELECT.

No point in manually splitting the SETCC if it was already done.

llvm-svn: 373535

llvm-svn: 373534

This is an effort to make RangeSpan and DebugLocStream::Entry more
similar to share code for their emission (to reuse the more complicated
code for using (& choosing when to use) base address selection entries,
etc).

It didn't seem like this struct was worth the complexity of
encapsulation - when the members could be initialized by the ctor to any
value (no validation) and the type is assignable (so there's no
mutability or other constraint being implemented by its interface).

llvm-svn: 373533

Speculative fix for Windows bot.

llvm-svn: 373532

The test fails to find the written file on Android.

llvm-svn: 373531

Should fix the current Windows buildbot failure.

llvm-svn: 373530

Summary:
All other stack trace callers assume that PC contains return address.
HWAsan already use GetNextInstructionPc in similar code.

PR43339

Reviewers: eugenis, kcc, jfb

Subscribers: dexonsmith, dberris, #sanitizers, llvm-commits

Tags: #sanitizers, #llvm

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

llvm-svn: 373529

llvm-svn: 373528

Summary:
This is the first of a series of patches extracted from a much bigger WIP
patch. It merely establishes the tblgen pass and the way empty combiner
helpers are declared and integrated into a combiner info.

The tablegen pass takes a -combiners option to select the combiner helper
that will be generated. This can be given multiple values to generate
multiple combiner helpers at once. Doing so helps to minimize parsing
overhead.

The reason for creating a GlobalISel subdirectory in utils/TableGen is that
there will be quite a lot of non-pass files (~15) by the time the patch
series is done.

Reviewers: volkan

Subscribers: mgorny, hiraditya, simoncook, Petar.Avramovic, s.egerton, llvm-commits

Tags: #llvm

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

llvm-svn: 373527

llvm-svn: 373526

The static analyzer is warning about potential null dereferences, but we should be able to use castAs<RecordType> directly and if not assert will fire for us.

llvm-svn: 373525

llvm-svn: 373524

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

llvm-svn: 373523

The cause for the revert should be fixed by r373513 /
a80b6c15

This reverts commit 47dbcbd8.

llvm-svn: 373522

The static analyzer is warning about potential null dereferences, but we should be able to use cast<>/castAs<> directly and if not assert will fire for us.

llvm-svn: 373520

Store rlwinm Rx, Ry, 32, 0, 31 as rlwinm Rx, Ry, 0, 0, 31 and store
rldicl Rx, Ry, 64, 0 as rldicl Rx, Ry, 0, 0. Otherwise SH field is overflow and
fails assertion in assembly printing stage.

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

llvm-svn: 373519

Summary:
https://reviews.llvm.org/D28596 exposed OnPrint in the global namespace,
which can cause collisions with user-defined OnPrint() functions.

Reviewers: vitalybuka, dvyukov

Reviewed By: vitalybuka, dvyukov

Subscribers: llvm-commits

Tags: #llvm

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

llvm-svn: 373518

This commit follows the trend of doing things per-target instead of
modifying the C++ flags globally. It does so for visibility-related
flags, other basic build flags and Windows-specific flags.

llvm-svn: 373517

The anonymous namespace starts out (incorrectly) indented but isn't
indented from the TimeRegionsOpt declaration onwards.

llvm-svn: 373516

Summary:
[MSan] handle llvm.launder.invariant.group

    Msan used to give false-positives in

    class Foo {
     public:
      virtual ~Foo() {};
    };

    // Return true iff *x is set.
    bool f1(void **x, bool flag);

    Foo* f() {
      void *p;
      bool found;
      found = f1(&p,flag);
      if (found) {
        // p is always set here.
        return static_cast<Foo*>(p); // False positive here.
      }
      return nullptr;
    }

Patch by Ilya Tokar.

Reviewers: #sanitizers, eugenis

Reviewed By: #sanitizers, eugenis

Subscribers: eugenis, Prazek, hiraditya, llvm-commits

Tags: #llvm

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

llvm-svn: 373515

llvm-svn: 373514

Terminators like invoke can have users outside the current basic block.
We have to replace those users with undef, before replacing the
terminator.

This fixes a crash exposed by rL373430.

Reviewers: brzycki, asbirlea, davide, spatel

Reviewed By: asbirlea

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

llvm-svn: 373513

This is part of a larger shift to move to per-target settings and
eradicate global variables from the CMake build. I'm starting small
with warnings only because those are easy to transition over and I
want to see how it pans out, but we can handle all flags like exceptions
and RTTI in the future.

llvm-svn: 373511

While around, clean up support for a 8 years old OS.

<rdar://problem/55916729>

llvm-svn: 373510

This code is only used under __arm64__, use the correct guard.

<rdar://problem/55916729>

llvm-svn: 373509

Another block that's only compiled on __arm64__ and wasn't
updated.

<rdar://problem/55916729>

llvm-svn: 373508

This didn't show up because nobody built __arm64__ in a while.

<rdar://problem/55916729>

llvm-svn: 373507

It turns out the benchmarks need to link against those libraries
explicitly too, so CMake's propagation of PUBLIC dependencies is
used.

llvm-svn: 373506

MemoryPhis should be added in the IDF of the blocks newly gaining Defs.
This includes the blocks that gained a Phi and the block gaining a Def,
if the block did not have one before.
Resolves PR43427.

llvm-svn: 373505

llvm-svn: 373504

llvm-svn: 373503

Context selectors may include optional score clause in format
`score(<expr>):`, where `<expr>` must be a constant integer expression.
Added parsing/sema analysis only.

llvm-svn: 373502

This patch is the final step in my quest to get rid of the JSON parser
in LLDB. Vedant's coverage report [1] shows that it was mostly untested.
Furthermore, the LLVM implementation has a much nicer API and using it
means one less thing to maintain for LLDB.

[1] http://lab.llvm.org:8080/coverage/coverage-reports/index.html

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

llvm-svn: 373501

This patch replaces the LLDB's JSON implementation with the one from
LLVM in GDBRemoteCommunicationServerCommon.

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

llvm-svn: 373500

This patch replaces the LLDB's JSON implementation with the one from
LLVM in GDBRemoteCommunicationServerPlatform.

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

llvm-svn: 373499

This patch replaces the LLDB's JSON implementation with the one from
LLVM in GDBRemoteCommunicationClient.

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

llvm-svn: 373498

This patch replaces the LLDB's JSON implementation with the one from
LLVM in GDBRemoteCommunicationServerLLGS.

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

llvm-svn: 373497

[X86] Rewrite to the vXi1 subvector insertion code to not rely on the value of bits that might be undef

The previous code tried to do a trick where we would extract the subvector from the location we were inserting. Then xor that with the new value. Take the xored value and clear out the bits above the subvector size. Then shift that xored subvector to the insert location. And finally xor that with the original vector. Since the old subvector was used in both xors, this would leave just the new subvector at the inserted location. Since the surrounding bits had been zeroed no other bits of the original vector would be modified.

Unfortunately, if the old subvector came from undef we might aggressively propagate the undef. Then we end up with the XORs not cancelling because they aren't using the same value for the two uses of the old subvector. @bkramer gave me a case that demonstrated this, but we haven't reduced it enough to make it easily readable to see what's happening.

This patch uses a safer, but more costly approach. It isolate the bits above the insertion and bits below the insert point and ORs those together leaving 0 for the insertion location. Then widens the subvector with 0s in the upper bits, shifts it into position with 0s in the lower bits. Then we do another OR.

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

llvm-svn: 373495