Summary:
__builtion___clear_cache maps to clear_cache function. On Linux,
clear_cache functions makes a syscall and does an abort if syscall fails.
Replace the abort by an assert so that non-debug builds do not abort
if the syscall fails.

Fixes PR34588.

Reviewers: rengolin, compnerd, srhines, peter.smith, joerg

Reviewed By: rengolin

Subscribers: aemerson, kristof.beyls, llvm-commits

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

llvm-svn: 314322

Followup for r314312 / r314313
Sorry, i really failed to fully grep all the codebase :/

llvm-svn: 314321

These changes faciliate positive behavior for arithmetic based select
expressions that match its translation criteria, keeping code size gated to
neutral or improved scenarios.

Patch by Michael Berg <michael_c_berg@apple.com>!

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

llvm-svn: 314320

Reviewers: mcrosier

Subscribers: aemerson, rengolin, javed.absar, kristof.beyls

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

llvm-svn: 314319

Fixing test failure on Android introduced in D38245. Compact size class
maps defined there are not to be used on Android.

llvm-svn: 314318

llvm-svn: 314317

llvm-svn: 314316

llvm-svn: 314315

Test failures.

llvm-svn: 314314

Fixup last commit, found by clang-stage1-cmake-RA-incremental bot.

llvm-svn: 314313

Summary:
Found when testing stage-2 build with D38101.

```
In file included from /build/llvm/lib/Support/Path.cpp:1045:
/build/llvm/lib/Support/Unix/Path.inc:648:14: error: comparison 'uint64_t' (aka 'unsigned long') > 18446744073709551615 is always false [-Werror,-Wtautological-constant-compare]
  if (length > std::numeric_limits<size_t>::max()) {
      ~~~~~~ ^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
```

`size_t` is `uint64_t` here, apparently, thus any `uint64_t` value
always fits into `size_t`.

Initial patch was to use some preprocessor logic to
not check if the size is known to fit at compile time.
But Zachary Turner suggested using this approach.

Reviewers: Bigcheese, rafael, zturner, mehdi_amini

Reviewed by (via email): zturner

Subscribers: llvm-commits

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

llvm-svn: 314312

Summary:
The current implementation of the allocator returning freed memory
back to OS (controlled by allocator_release_to_os_interval_ms flag)
requires sorting of the free chunks list, which has two major issues,
first, when free list grows to millions of chunks, sorting, even the
fastest one, is just too slow, and second, sorting chunks in place
is unacceptable for Scudo allocator as it makes allocations more
predictable and less secure.

The proposed approach is linear in complexity (altough requires quite
a bit more temporary memory). The idea is to count the number of free
chunks on each memory page and release pages containing free chunks
only. It requires one iteration over the free list of chunks and one
iteration over the array of page counters. The obvious disadvantage
is the allocation of the array of the counters, but even in the worst
case we support (4T allocator space, 64 buckets, 16 bytes bucket size,
full free list, which leads to 2 bytes per page counter and ~17M page
counters), requires just about 34Mb of the intermediate buffer (comparing
to ~64Gb of actually allocated chunks) and usually it stays under 100K
and released after each use. It is expected to be a relatively rare event,
releasing memory back to OS, keeping the buffer between those runs
and added complexity of the bookkeeping seems unnesessary here (it can
always be improved later, though, never say never).

The most interesting problem here is how to calculate the number of chunks
falling into each memory page in the bucket. Skipping all the details,
there are three cases when the number of chunks per page is constant:
  1) P >= C, P % C == 0 --> N = P / C
  2) C > P , C % P == 0 --> N = 1
  3) C <= P, P % C != 0 && C % (P % C) == 0 --> N = P / C + 1
where P is page size, C is chunk size and N is the number of chunks per
page and the rest of the cases, where the number of chunks per page is
calculated on the go, during the page counter array iteration.

Among the rest, there are still cases where N can be deduced from the
page index, but they require not that much less calculations per page
than the current "brute force" way and 2/3 of the buckets fall into
the first three categories anyway, so, for the sake of simplicity,
it was decided to stick to those two variations. It can always be
refined and improved later, should we see that brute force way slows
us down unacceptably.

Reviewers: eugenis, cryptoad, dvyukov

Subscribers: kubamracek, mehdi_amini, llvm-commits

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

llvm-svn: 314311

Before this change using any of the -name*= command line options with an output
directory would result in a single file (functions.txt/functions.html)
containing the coverage for those specific functions. Now you get the same
directory structure as when not using any -name*= options.

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

llvm-svn: 314310

Summary:
The root Uri is the workspace location and will be useful in the context of
indexing. We could also add more things to InitializeParams in order to
configure Clangd for C/C++ sepecific extensions.

Reviewers: ilya-biryukov, bkramer, krasimir, Nebiroth

Reviewed By: ilya-biryukov

Subscribers: ilya-biryukov

Tags: #clang-tools-extra

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

llvm-svn: 314309

This was intended to be no-functional-change, but it's not - there's a test diff.

So I thought I should stop here and post it as-is to see if this looks like what was expected 
based on the discussion in PR34603:
https://bugs.llvm.org/show_bug.cgi?id=34603

Notes:
 1. The test improvement occurs because the existing 'LateSimplifyCFG' marker is not carried 
    through the recursive calls to 'SimplifyCFG()->SimplifyCFGOpt().run()->SimplifyCFG()'. 
    The parameter isn't passed down, so we pick up the default value from the function signature 
    after the first level. I assumed that was a bug, so I've passed 'Options' down in all of the 
    'SimplifyCFG' calls.

 2. I split 'LateSimplifyCFG' into 2 bits: ConvertSwitchToLookupTable and KeepCanonicalLoops. 
    This would theoretically allow us to differentiate the transforms controlled by those params 
    independently.

 3. We could stash the optional AssumptionCache pointer and 'LoopHeaders' pointer in the struct too. 
    I just stopped here to minimize the diffs.

 4. Similarly, I stopped short of messing with the pass manager layer. I have another question that 
    could wait for the follow-up: why is the new pass manager creating the pass with LateSimplifyCFG 
    set to true no matter where in the pipeline it's creating SimplifyCFG passes?

    // Create an early function pass manager to cleanup the output of the
    // frontend.
    EarlyFPM.addPass(SimplifyCFGPass());

    -->

    /// \brief Construct a pass with the default thresholds
    /// and switch optimizations.
    SimplifyCFGPass::SimplifyCFGPass()
       : BonusInstThreshold(UserBonusInstThreshold),
         LateSimplifyCFG(true) {}   <-- switches get converted to lookup tables and loops may not be in canonical form

    If this is unintended, then it's possible that the current behavior of dropping the 'LateSimplifyCFG' 
    setting via recursion was masking this bug.

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

llvm-svn: 314308

InlineCost can understand Select IR now.  This patch finds free Select IRs and
continue the propagation of SimplifiedValues, ConstantOffsetPtrs, and
SROAArgValues.

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

llvm-svn: 314307

NFC.
 Updated 8 regression tests to use -mattr instead of -mcpu flag as follows:
 -mcpu=knl --> -mattr=+avx512f
 -mcpu=skx --> -mattr=+avx512f,+avx512bw,+avx512vl,+avx512dq

The updates are as part of the preparation of a large commit to add all instruction scheduling for the SKX target.

Reviewers: delena, zvi, RKSimon
Differential Revision: https://reviews.llvm.org/D38222

Change-Id: I2381c9b5bb75ecacfca017243c22d054f6eddd14
llvm-svn: 314306

Summary:
Adding tests for D37534.

Commit on behalf of julia.koval@intel.com

Reviewers: n.bozhenov, zvi, spatel, DavidKreitzer

Reviewed By: zvi

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

llvm-svn: 314305

Added missing addrspacecast case in alignment computation
logic of pointer type emission in IR generation.

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

llvm-svn: 314304

Summary: Test for checking if the mapping is performed correctly. This is a test initially included in Patch https://reviews.llvm.org/D29905

Reviewers: Hahnfeld, carlo.bertolli, caomhin, ABataev

Reviewed By: Hahnfeld

Subscribers: tra, cfe-commits

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

llvm-svn: 314303

accidently added only tests w/o the respective changes..

llvm-svn: 314302

llvm-svn: 314301

Allow the proper recognition of Enum values and global variables inside ms inline-asm memory / immediate expressions, as they require some additional overhead and treated incorrect if doesn't early recognized.
supersedes D33277, D35775
Corrsponds with D37412, D37413

llvm-svn: 314300

llvm-svn: 314299

llvm-svn: 314298

This patch makes analyzeBranch eliminate unconditional branch to the next instruction.
After basic blocks are re-organized by optimizers, such as machine block placement, a BB may end with an unconditional branch to the next (fallthrough) BB. This patch removes such redundant branch instruction.

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

llvm-svn: 314297

Reviewed by: @MatzeB
Differential Revision: https://reviews.llvm.org/D38176

llvm-svn: 314296

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

llvm-svn: 314295

The exact values of the .debug_line offsets should not be hard-coded in
the checks for bitcode tests.

Fixes: http://bb.pgr.jp/builders/test-llvm-i686-linux-RA/builds/543
llvm-svn: 314294

As commented on D37849 and rL313547, AVX1 targets were missing a chance to use vmovmskpd for v4f64/v4i64 results for bool vector bitcasts

llvm-svn: 314293

llvm-svn: 314292

Fixes 32-bit buildbots:
  http://bb.pgr.jp/builders/test-llvm-i686-linux-RA/builds/542
  http://lab.llvm.org:8011/builders/clang-cmake-thumbv7-a15/builds/11533
  http://lab.llvm.org:8011/builders/clang-cmake-armv7-a15/builds/11494

llvm-svn: 314291

This function can now track null pointer through simple pointer arithmetic,
such as '*&*(p + 2)' => 'p' and so on, displaying intermediate diagnostic pieces
for the user to understand where the null pointer is coming from.

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

llvm-svn: 314290

llvm-svn: 314289

This patch adds support for passing an offset to -debug-line.

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

llvm-svn: 314288

This API is used by checkers (and other entities) in order to track where does
a value originate from, by jumping from an expression value of which is equal
to that value to the expression from which this value has "appeared". For
example, it may be an lvalue from which the rvalue was loaded, or a function
call from which the dereferenced pointer was returned.

The function now avoids incorrectly unwrapping implicit lvalue-to-rvalue casts,
which caused crashes and incorrect intermediate diagnostic pieces. It also no
longer relies on how the expression is written when guessing what it means.

Fixes pr34373 and pr34731.

rdar://problem/33594502

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

llvm-svn: 314287

This patch adds support for passing an offset to -debug-loc.

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

llvm-svn: 314286

Summary:
clang does not assemble files in thumb mode unless .thumb declaration
is present. Add .thumb/.arm decl to _FUNCTION macros to ensure that
files are assembled correctly.

Fixes PR 34715.

Reviewers: compnerd, peter.smith, srhines, weimingz, rengolin

Reviewed By: compnerd

Subscribers: aemerson, javed.absar, llvm-commits, kristof.beyls

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

llvm-svn: 314285

Summary:
MSR instruction in Thumb2 does not support immediate operand.
Fix this by moving the condition for V7-M to Thumb2 since V7-M support
Thumb2 only. With this change, aeabi_cfcmp.s and aeabi_cdcmp.S files can
be assembled in Thumb2 mode. (This is split out from the review D38227).

Reviewers: compnerd, peter.smith, srhines, weimingz, rengolin, kristof.beyls

Reviewed By: compnerd

Subscribers: aemerson, javed.absar, llvm-commits

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

llvm-svn: 314284

Detemplation of one more synthetic section.

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

llvm-svn: 314283