This broke the windows buildbots, revert for now.

This reverts commit 24050b5ddef42f6f3306aa94d4a1f42a7893a9a7.

llvm-svn: 314347

always set LLVM_ENABLE_DUMP=ON for +Asserts builds.

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

llvm-svn: 314346

FileOutputBuffer::create() attempts to remove a target file if the file
is a regular one, which results in an unexpected result in a failure
scenario.

If something goes wrong and the user of FileOutputBuffer decides to not
call commit(), it leaves nothing. An existing file is removed, and no
new file is created.

What we should do is to atomically replace an existing file with a new
file using rename(), so that it wouldn't remove an existing file without
creating a new one.

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

llvm-svn: 314345

Summary:
Weird failure where `errno != ENOMEM` on valloc failure. The returned pointer
is null since it passes the previous assert, so this shouldn't happen.

http://lab.llvm.org:8011/builders/clang-cmake-armv7-a15-full/builds/10931
http://lab.llvm.org:8011/builders/clang-cmake-thumbv7-a15-full-sh/builds/2469

Disabling until we figure out what's going on.

Reviewers: alekseyshl

Reviewed By: alekseyshl

Subscribers: aemerson, srhines, llvm-commits, kristof.beyls

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

llvm-svn: 314344

whose isa is an index instead of a pointer.  Currently, this type
of isa encoding is only used on watchos.
<rdar://problem/34675497> 

llvm-svn: 314343

Change-Id: I5594bd6b216deca2c73cf0a7001f9aec1e803c60
llvm-svn: 314342

This commit allows the outliner to avoid saving and restoring the link register
on AArch64 when it is dead within an entire class of candidates.

This introduces changes to the way the outliner interfaces with the target.
For example, the target now interfaces with the outliner using a
MachineOutlinerInfo struct rather than by using getOutliningCallOverhead and
getOutliningFrameOverhead.

This also improves several comments on the outliner's cost model.

https://reviews.llvm.org/D36721

llvm-svn: 314341

Removes semicolons after if {} blocks, function definitions, etc.
I was able to apply the large OMPT patch cleanly on top of this one
with no conflicts.

llvm-svn: 314340

Revert r314249 "Recommit r314151 "[X86] Make all the NOREX CodeGenOnly instructions into postRA pseudos like the NOREX version of TEST."""

This caused PR34751

llvm-svn: 314339

This contributed to PR34751

llvm-svn: 314338

Hopefully this will make it easier to vary the combine depth threshold per-target.

llvm-svn: 314337

ExternalASTMerger has hitherto relied on being able to look up 
any Decl through its named DeclContext chain. This works for 
many cases, but causes problems for function-local structs, 
which cannot be looked up in their containing FunctionDecl. An
example case is

void f() {
  { struct S { int a; }; }
  { struct S { bool b; }; }
}

It is not possible to lookup either of the two Ses individually 
(or even to provide enough information to disambiguate) after 
parsing is over; and there is typically no need to, since they 
are invisible to the outside world.

However, ExternalASTMerger needs to be able to complete either 
S on demand. This led to an XFAIL on test/Import/local-struct, 
which this patch removes. The way the patch works is:

It defines a new data structure, ExternalASTMerger::OriginMap,
which clients are expected to maintain (default-constructing 
if the origin does not have an ExternalASTMerger servicing it)
As DeclContexts are imported, if they cannot be looked up by 
name they are placed in the OriginMap. This allows 
ExternalASTMerger to complete them later if necessary.
As DeclContexts are imported from an origin that already has 
its own OriginMap, the origins are forwarded – but only for 
those DeclContexts that are actually used. This keeps the 
amount of stored data minimal.

The patch also applies several improvements from review:

- Thoroughly documents the interface to ExternalASTMerger;
- Adds optional logging to help track what's going on; and
- Cleans up a bunch of braces and dangling elses.

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

llvm-svn: 314336

Summary:
According to https://gcc.gnu.org/wiki/SplitStacks, the linker expects a zero-sized .note.GNU-split-stack section if split-stack is used (and also .note.GNU-no-split-stack section if it also contains non-split-stack functions), so it can handle the cases where a split-stack function calls non-split-stack function.

This change adds the sections if needed.

Fixes PR #34670.

Reviewers: thanm, rnk, luqmana

Reviewed By: rnk

Subscribers: llvm-commits

Patch by Cherry Zhang <cherryyz@google.com>

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

llvm-svn: 314335

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

llvm-svn: 314334

Revert r314284, r314285 and r314289 because of a reported
breakage in armv7k watchos builder.

llvm-svn: 314333

We already have zeroable bits in an APInt. We might as well use that instead of checking for an all zero BUILD_VECTOR.

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

llvm-svn: 314332

[X86] In combineLoopSADPattern, pad result with zeros and use full size add instead of using a smaller add and inserting.

In some cases the result psadbw is smaller than the type of the add that started the match. Currently in these cases we are using a smaller add and inserting the result.

If we instead combine the psadbw with zeros and use the full size add we can take advantage of implicit zeroing we get if we emit a narrower move before the add.

In a future patch, I want to make isel aware that the psadbw itself already zeroed the upper bits and remove the move entirely.

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

llvm-svn: 314331

ToolChain::TranslateArgs() returns nullptr if no changes are performed.
This would currently mean that OpenMPArgs are lost. Patch fixes this
by falling back to simply using OpenMPArgs in that case.

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

llvm-svn: 314330

AuxTriple is not set if host and device share a toolchain. Also,
removing an argument modifies the DAL which needs to be returned
for future use.
(Move tests back to offload-openmp.c as they are not related to GPUs.)

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

llvm-svn: 314329

Parsing the argument after -Xopenmp-target allocates memory that needs
to be freed. Associate it with the final DerivedArgList after we know
which one will be used.

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

llvm-svn: 314328

https://reviews.llvm.org/rL299952 merged '>>>' tokens into a single
JavaRightLogicalShift token. This broke formatting of generics nested more than
two deep, e.g. Foo<Bar<Baz>>> because the '>>>' now weren't three '>' for
parseAngle().

Luckily, just deleting JavaRightLogicalShift fixes things without breaking the
test added in r299952, so do that.

https://reviews.llvm.org/D38291

llvm-svn: 314325

reductions.

If both operands of the newly created SelectInst are Undefs the
resulting operation is also Undef, not SelectInst. It may cause crashes
when trying to propagate IR flags because function expects exactly
SelectInst instruction, nothing else.

llvm-svn: 314323

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