Patch tries to improve vectorization of the following code:
    
            void add1(int * __restrict dst, const int * __restrict src) {
              *dst++ = *src++;
              *dst++ = *src++ + 1;
              *dst++ = *src++ + 2;
              *dst++ = *src++ + 3;
            }
            Allows to vectorize even if the very first operation is not a binary add, but just a load.
    
            Fixed issues related to previous commit.
    
            Reviewers: spatel, mzolotukhin, mkuper, hfinkel, RKSimon, filcab, ABataev
    
            Reviewed By: ABataev, RKSimon
    
            Subscribers: llvm-commits, RKSimon
    
            Differential Revision: https://reviews.llvm.org/D28907

llvm-svn: 319531

The latest clang that ships with Xcode (clang 900 or 9.0.0) does not
support LSan. This fixes the lit configuration to reflect that.

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

llvm-svn: 319530

This reverts commit r319525.

This change has introduced a problem with the Lit tests build for compiler-rt using Gold: http://lab.llvm.org:8011/builders/sanitizer-x86_64-linux/builds/6047/steps/test%20standalone%20compiler-rt/logs/stdio

llvm-lit: /b/sanitizer-x86_64-linux/build/llvm/utils/lit/lit/TestingConfig.py:101: fatal: unable to parse config file '/b/sanitizer-x86_64-linux/build/llvm/projects/compiler-rt/test/profile/Linux/lit.local.cfg', traceback: Traceback (most recent call last):
  File "/b/sanitizer-x86_64-linux/build/llvm/utils/lit/lit/TestingConfig.py", line 88, in load_from_path
    exec(compile(data, path, 'exec'), cfg_globals, None)
  File "/b/sanitizer-x86_64-linux/build/llvm/projects/compiler-rt/test/profile/Linux/lit.local.cfg", line 37, in <module>
    if root.host_os not in ['Linux'] or not is_gold_linker_available():
  File "/b/sanitizer-x86_64-linux/build/llvm/projects/compiler-rt/test/profile/Linux/lit.local.cfg", line 27, in is_gold_linker_available
    stderr = subprocess.PIPE)
  File "/usr/lib/python2.7/subprocess.py", line 390, in __init__
    errread, errwrite)
  File "/usr/lib/python2.7/subprocess.py", line 1024, in _execute_child
    raise child_exception
OSError: [Errno 2] No such file or directory
llvm-svn: 319529

Summary:
The internal shell already supports 'cd', ‘export’ and ‘echo’ commands.
This patch adds implementation of non-pipelined ‘mkdir’, ‘diff’ and ‘rm’
commands as the internal shell builtins.

Reviewed by: Zachary Turner, Reid Kleckner

Subscribers: llvm-commits

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

llvm-svn: 319528

It is a follow up for 
https://reviews.llvm.org/D40652 requested during review.

llvm-svn: 319527

[ELF] - Produce relocation section name consistent with output section name when --emit-reloc used with linker script.

This is for "Bug 35474 - --emit-relocs produces wrongly-named reloc sections".

LLD currently for scripts like:

.text.boot : { *(.text.boot) }
emits relocation section with name .rela.text because does not take
redefined name of output section into account and builds section name
using rules for non-scripted case. Patch fixes this oddness.

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

llvm-svn: 319526

Summary:
As discussed in https://github.com/google/oss-fuzz/issues/933,
it would be really awesome to be able to use ThinLTO for fuzzing.
However, as @kcc has pointed out, it is currently undefined (untested)
whether the sanitizers actually function properly with LLD and/or LTO.

This patch is inspired by the cfi test, which already do test with LTO
(and/or LLD), since LTO is required for CFI to function.

I started with UBSan, because it's cmakelists / lit.* files appeared
to be the cleanest. This patch adds the infrastructure to easily add
LLD and/or LTO sub-variants of the existing lit test configurations.

Also, this patch adds the LLD flavor, that explicitly does use LLD to link.
The check-ubsan does pass on my machine. And to minimize the [initial]
potential buildbot breakage i have put some restrictions on this flavour.

Please review carefully, i have not worked with lit/sanitizer tests before.

Reviewers: eugenis, vitalybuka

Reviewed By: eugenis

Subscribers: #sanitizers, pcc, kubamracek, mgorny, llvm-commits, mehdi_amini, inglorion, kcc

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

llvm-svn: 319525

Summary: LegalizerInfo assumes all G_MERGE_VALUES and G_UNMERGE_VALUES instructions are legal, so it is not possible to legalize vector operations on illegal vector types. This patch fixes the problem by removing the related check and adding default actions for G_MERGE_VALUES and G_UNMERGE_VALUES.

Reviewers: qcolombet, ab, dsanders, aditya_nandakumar, t.p.northover, kristof.beyls

Reviewed By: dsanders

Subscribers: rovka, javed.absar, igorb, llvm-commits

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

llvm-svn: 319524

Use this source use on Fuchsia where this is the oficially way
to obtain randomness. This could be also used on other platforms
that already support getentropy such as *BSD or Linux.

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

llvm-svn: 319523

Recommiting once reverted patch rL319407 after adding a check for bit vector size to avoid failures in some build bots.

llvm-svn: 319522

The default legalization for v2i32 is promotion to v2i64. This results in a gather that reads 64-bit elements rather than 32. If one of the elements is near a page boundary this can cause an illegal access that can fault.

We also miscalculate the scale for the gather which is an even worse problem, but we probably could have found a separate way to fix that.

llvm-svn: 319521

[X86][SelectionDAG] Make sure we explicitly sign extend the index when type promoting the index of scatter and gather.

Type promotion makes no guarantee about the contents of the promoted bits. Since the gather/scatter instruction will use the bits to calculate addresses, we need to ensure they aren't garbage.

llvm-svn: 319520

llvm-svn: 319519

llvm-svn: 319518

This adds install-*-stripped targets that strip during installation.

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

llvm-svn: 319517

When it does, it returns a NULL ClassTemplateDecl.  Don't use 
it if it is NULL...

<rdar://problem/35672107>

llvm-svn: 319516

AddLLVM is needed for several functions that are used in tests and
as such needs to be included from the right context which previously
wasn't the case.

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

llvm-svn: 319515

AVX2 gathers only use the upper bit of the mask allowing us to simplify sign_extend_inreg to a shift left.

llvm-svn: 319514

No CodeGen support for MSABI yet, we don't know how to mangle this there.

llvm-svn: 319513

llvm-svn: 319512

This will be used in https://github.com/apple/swift/pull/12938

llvm-svn: 319511

Summary:
Support was added in rL319488 but these tests were not
updated.

Subscribers: jfb, dschuff, jgravelle-google, aheejin, sunfish

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

llvm-svn: 319510

llvm-svn: 319509

This reverts commit r318699, it is breaking 32-bit SEH handlers in
Chromium.

llvm-svn: 319508

Even with the sparse file optimizations the SYM64 test can still be painfully
slow. This unnecessarily slows down devs. It's critical that we test that the
switch to the SYM64 format occurs at 4GB but there isn't any better of a way to
fake the size of the file than sparse files. This change introduces a flag that
allows the cutoff to be arbitrarily set to whatever power of two is desired.
The flag is hidden as it really isn't meant to be used outside this one test.
This is unfortunate but appears necessary, at least until the average hard
drive is much faster.

The changes to the test require some explanation. Prior to this change we knew
that the SYM64 format was being used because the file was simply too large to
have validly handled this case if the SYM64 format were not used. To ensure
that the SYM64 format is still being used I am grepping the file for "SYM64".
Without changing the filename however this would be pointless because "SYM64"
would occur in the file either way. So the filename of the test is also changed
in order to avoid this issue.

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

llvm-svn: 319507

Patch by Nicholas Wilson

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

llvm-svn: 319506

These command line options are not intended for public use, and often
don't even make sense in the context of a particular tool anyway. About
90% of them are already hidden, but when people add new options they
forget to hide them, so if you were to make a brand new tool today, link
against one of LLVM's libraries, and run tool -help you would get a
bunch of junk that doesn't make sense for the tool you're writing.

This patch hides these options. The real solution is to not have
libraries defining command line options, but that's a much larger effort
and not something I'm prepared to take on.

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

llvm-svn: 319505

This is basically a proof-of-concept and starting point for having a
testing-centric tool in LLDB.  I'm sure this leaves a lot of room to be
desired, but this at least allows us to have something to build on.

Right now there is only one command, the `module-sections` command, and I
created this command not because it was particularly special, but
because it addressed an immediate use case and was extremely simple.

Run the tool as `lldb-test module-sections <path-to-object>`.

Feel free to add testing related stuff to your heart's content after
this goes in.  Implementing the commands themselves takes some work, but
once they're there they can be reused without writing any code and
result in very easy to use and maintain tests.

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

llvm-svn: 319504

Our on-disk hash table was unnecessarily large. The cost of collision is
not high in the .gnu.hash table because each symbol in the .gnu.hash
table has a hash value with it. So, for each collided symbol, the
dynamic linker just compares an integer, which is pretty cheap.

This patch increases the load factor by about 8. Here's a comparison.

  $ readelf --histogram libclangSema.so.6.0.0svn-new-lld
  Histogram for `.gnu.hash' bucket list length (total of 582 buckets):
   Length  Number     % of total  Coverage
        0  11         (  1.9%)
        1  35         (  6.0%)      1.5%
        2  93         ( 16.0%)      9.5%
        3  108        ( 18.6%)     23.4%
        4  121        ( 20.8%)     44.1%
        5  86         ( 14.8%)     62.6%
        6  63         ( 10.8%)     78.8%
        7  38         (  6.5%)     90.2%
        8  18         (  3.1%)     96.4%
        9  6          (  1.0%)     98.7%
       10  3          (  0.5%)    100.0%

  $ readelf --histogram libclangSema.so.6.0.0svn-old-lld
  Histogram for `.gnu.hash' bucket list length (total of 4093 buckets):
   Length  Number     % of total  Coverage
        0  1498       ( 36.6%)
        1  1545       ( 37.7%)     37.7%
        2  712        ( 17.4%)     72.5%
        3  251        (  6.1%)     90.9%
        4  66         (  1.6%)     97.3%
        5  16         (  0.4%)     99.3%
        6  5          (  0.1%)    100.0%

  $ readelf --histogram libclangSema.so.6.0.0svn-bfd
  Histogram for `.gnu.hash' bucket list length (total of 1004 buckets):
   Length  Number     % of total  Coverage
      0  92         (  9.2%)
        1  227        ( 22.6%)      9.8%
        2  266        ( 26.5%)     32.6%
        3  222        ( 22.1%)     61.2%
        4  115        ( 11.5%)     81.0%
        5  55         (  5.5%)     92.8%
        6  21         (  2.1%)     98.2%
        7  6          (  0.6%)    100.0%

  $ readelf --histogram libclangSema.so.6.0.0svn-gold
  Histogram for `.gnu.hash' bucket list length (total of 2053 buckets):
   Length  Number     % of total  Coverage
        0  671        ( 32.7%)
        1  709        ( 34.5%)     30.4%
        2  470        ( 22.9%)     70.7%
        3  141        (  6.9%)     88.9%
        4  54         (  2.6%)     98.2%
        5  5          (  0.2%)     99.2%
        6  3          (  0.1%)    100.0%

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

llvm-svn: 319503

llvm-svn: 319502

llvm-svn: 319501

but still listed in the kernel's kext table with the kernel
binary UUID.  This resulted in the kernel text section being
loaded at the kext address and problems ensuing.  Instead,
if there is a kext with the same UUID as the kernel, lldb
should skip over it.

<rdar://problem/35757689> 

llvm-svn: 319500

LLVM is gaining install-*-stripped targets to perform stripped installs,
and in order for this to be useful for install-distribution, all
potential distribution components should have stripped installation
targets. LLVM has a function to create these install targets, but since
we can't use LLVM CMake functions in libc++abi, let's do it manually.

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

llvm-svn: 319499

This gains us the install-unwind-stripped target, to perform stripping
during installation.

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

llvm-svn: 319498

llvm-svn: 319497

llvm-svn: 319496

Update website to mention that you still need -frelaxed-template-template-args to enable the corresponding C++17 feature in Clang 5.

llvm-svn: 319495

If the thin module has no references to an internal global in the
merged module, we need to make sure to preserve that property if the
global is a member of a comdat group, as otherwise promotion can end
up adding global symbols to the comdat, which is not allowed.

This situation can arise if the external global in the thin module
has dead constant users, which would cause use_empty() to return
false and would cause us to try to promote it. To prevent this from
happening, discard the dead constant users before asking whether a
global is empty.

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

llvm-svn: 319494

This was storing the hash alongside the key so that the hash
doesn't need to be re-computed every time, but in doing so it
was allocating a structure to keep the key size small in the
DenseMap.  This is a noble goal, but it also leads to a pointer
indirection on every probe, and this cost of this pointer
indirection ends up being higher than the cost of having a
slightly larger entry in the hash table.  Removing this not only
simplifies the code, but yields a small but noticeable
performance improvement in the type merging algorithm.

llvm-svn: 319493

1. Move TaskPool into the namespace lldb_private.
2. Add missing std::move in TaskPoolImpl::Worker.
3. std::thread::hardware_concurrency may return 0,
handle this case correctly.

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

Test plan: make check-all

llvm-svn: 319492