llvm-svn: 293390

[libfuzzer] include errno.h. On Ubuntu 14.04 we got away w/o it, but other systems seem to require it

llvm-svn: 293389

llvm-svn: 293388

llvm-svn: 293387

The jumbled scalar loads will be sorted while building the tree and these accesses will be marked to generate shufflevector after the vectorized load with proper mask.

Reviewers: hfinkel, mssimpso, mkuper

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

Change-Id: I9c0c8e6f91a00076a7ee1465440a3f6ae092f7ad
llvm-svn: 293386

The symbols _end, end, _etext, etext, _edata, edata and __ehdr_start
refer to positions in the file and are therefore not absolute. Making
them absolute was on unfortunate cargo cult of what bfd was doing.

Changing the symbols allows for pc relocations to them to be resolved,
which should fix the wine build.

llvm-svn: 293385

Support for barrier synchronization between a subset of threads
in a CTA through one of sixteen explicitly specified barriers.
These intrinsics are not directly exposed in CUDA but are
critical for forthcoming support of OpenMP on NVPTX GPUs.

The intrinsics allow the synchronization of an arbitrary
(multiple of 32) number of threads in a CTA at one of 16
distinct barriers. The two intrinsics added are as follows:

call void @llvm.nvvm.barrier.n(i32 10)
waits for all threads in a CTA to arrive at named barrier #10.

call void @llvm.nvvm.barrier(i32 15, i32 992)
waits for 992 threads in a CTA to arrive at barrier #15.

Detailed description of these intrinsics are available in the PTX manual.
http://docs.nvidia.com/cuda/parallel-thread-execution/#parallel-synchronization-and-communication-instructions

Reviewers: hfinkel, jlebar
Differential Revision: https://reviews.llvm.org/D17657

llvm-svn: 293384

llvm-svn: 293383

llvm-svn: 293382

llvm-svn: 293381

llvm-svn: 293380

llvm-svn: 293379

This addresses some additional comments from Michael Kruse for commit r293374
as expressed in https://reviews.llvm.org/D28901.

llvm-svn: 293378

Summary:
Patch by Michele Scandale
(with a small tweak to 'CHECK-NOT' the last DILocation in the test)

Subscribers: bogner, llvm-commits

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

llvm-svn: 293377

It's now emitCxxPredicateListExpr() to better match the class name.

llvm-svn: 293376

This fixes some destruction-of-locked-mutex errors in RawByteChannel.

llvm-svn: 293375

Instead of keeping two separate maps from Value to Allocas, one for
MemoryType::Value and the other for MemoryType::PHI, we introduce a single map
from ScopArrayInfo to the corresponding Alloca. This change is intended, both as
a general simplification and cleanup, but also to reduce our use of
MemoryAccess::getBaseAddr(). Moving away from using getBaseAddr() makes sure
we have only a single place where the array (and its base pointer) for which we
generate code for is specified, which means we can more easily introduce new
access functions that use a different ScopArrayInfo as base. We already today
experiment with modifiable access functions, so this change does not address
a specific bug, but it just reduces the scope one needs to reason about.

Another motivation for this patch is https://reviews.llvm.org/D28518, where
memory accesses with different base pointers could possibly be mapped to a
single ScopArrayInfo object. Such a mapping is currently not possible, as we
currently generate alloca instructions according to the base addresses of the
memory accesses, not according to the ScopArrayInfo object they belong to.  By
making allocas ScopArrayInfo specific, a mapping to a single ScopArrayInfo
object will automatically mean that the same stack slot is used for these
arrays. For D28518 this is not a problem, as only MemoryType::Array objects are
mapping, but resolving this inconsistency will hopefully avoid confusion.

llvm-svn: 293374

In order to make sure that LLVM continues to work on machines that do not have the Universal CRT yet,
we'll need to ship a copy of UCRT in the Windows installation package. Fortunately, CMake 3.6+ already
supports app-local deployment of UCRT dlls, we just need to turn this on.

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

llvm-svn: 293373

Summary: Along with https://reviews.llvm.org/D27804, debug locations need to be merged when hoisting store instructions as well. Not sure if just dropping debug locations would make more sense for this case, but as the branch instruction will have at least different discriminator with the hoisted store instruction, I think there will be no difference in practice.

Reviewers: aprantl, andreadb, danielcdh

Reviewed By: aprantl

Subscribers: llvm-commits

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

llvm-svn: 293372

llvm-svn: 293371

llvm-svn: 293370

r293360 broke some ARM bots, because size_t on those targets is
apparently `unsigned int`, not `unsigned long`. `sizeof(whatever)`
should to give us a `size_t`, so we can just use the type of that
instead.

llvm-svn: 293369

This fixes non-debug non-assert builds after r293359.

llvm-svn: 293368

non-template function instantiated from a friend declaration in a class
template from TSK_ImplicitInstantiation to TSK_Undeclared.

It doesn't make sense for a non-template function to be flagged as being
instantiated from a template; that property really belongs to the entity
as a whole and not an individual declaration of it. There's some history
here:

 * r137934 started marking these functions as instantiations in order to
   work around an issue where we might instantiate a class template while
   we're still parsing its member definitions, and would otherwise fail
   to instantiate the friend definition

 * r177003 fixed the same issue but for friend templates, but did so by
   making the friends claim to be definitions even before we'd parsed
   their actual bodies; this made the r137934 change redundant

 * r293558 worked around a problem caused by the marking of a non-template
   function as a template instantiation in r137934

This change reverts the code changes from r293358 and r137934 and retains
all the tests.

llvm-svn: 293367

header line, backtrace output) was to remove the current pc value
from frames where we have source level information.  We've been
discussing this for the past week and based on input from a group
of low level users, I believe this is the wrong default behavior
for the command line lldb tool.

lldb's backtrace will include the pc value for all stack frames
regardless of whether they have source level debug information or
not.  

A related part of r286288 removes the byte offset printing for
functions with source level information (e.g. "main + 22 sourcefile.c:10"
is printed as "main sourcefile.c:10").  I don't see a compelling
case for changing this part of 286288 so I'm leaving that as-is
(in addition to the rest of 286288 which is clearly better than
the previous output style).

<rdar://problem/30083904> 

llvm-svn: 293366

The dump() functions are meant to be used in a debugger, code should
typically use something like print(errs());

llvm-svn: 293365

dump() is only available in debug builds and meant for debugger usage,
normal code should use something like print(errs());

llvm-svn: 293364

Summary: Extend the MemorySSAUpdater API to allow movement to arbitrary places

Reviewers: davide, george.burgess.iv

Subscribers: llvm-commits

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

llvm-svn: 293363

When the OperandsMapper creates virtual registers, it used to just create
plain scalar register with the right size. This may confuse the
instruction selector because we lose the information of the instruction
using those registers what supposed to do. The MachineVerifier complains
about that already.

With this patch, the OperandsMapper still creates plain scalar register,
but the expectation is for the mapping function to remap the type
properly. The default mapping function has been updated to do that.

rdar://problem/30231850

llvm-svn: 293362

llvm-svn: 293361

This patch changes how we handle argument-dependent `diagnose_if`
attributes. In particular, we now check them in the same place that we
check for things like passing NULL to Nonnull args, etc. This is
basically better in every way than how we were handling them before. :)

This fixes PR31638, PR31639, and PR31640.

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

llvm-svn: 293360

We had various variants of defining dump() functions in LLVM. Normalize
them (this should just consistently implement the things discussed in
http://lists.llvm.org/pipermail/cfe-dev/2014-January/034323.html

For reference:
- Public headers should just declare the dump() method but not use
  LLVM_DUMP_METHOD or #if !defined(NDEBUG) || defined(LLVM_ENABLE_DUMP)
- The definition of a dump method should look like this:
  #if !defined(NDEBUG) || defined(LLVM_ENABLE_DUMP)
  LLVM_DUMP_METHOD void MyClass::dump() {
    // print stuff to dbgs()...
  }
  #endif

llvm-svn: 293359

were nonetheless instantiated (particularly, non-template friends declared
within class templates).

llvm-svn: 293358

llvm-svn: 293357

insertUse, moveBefore and moveAfter operations.

Summary:
This creates a basic MemorySSA updater that handles arbitrary
insertion of uses and defs into MemorySSA, as well as arbitrary
movement around the CFG. It replaces the current splice API.

It can be made to handle arbitrary control flow changes.
Currently, it uses the same updater algorithm from D28934.

The main difference is because MemorySSA is single variable, we have
the complete def and use list, and don't need anyone to give it to us
as part of the API.  We also have to rename stores below us in some
cases.

If we go that direction in that patch, i will merge all the updater
implementations (using an updater_traits or something to provide the
get* functions we use, called read*/write* in that patch).

Sadly, the current SSAUpdater algorithm is way too slow to use for
what we are doing here.

I have updated the tests we have to basically build memoryssa
incrementally using the updater api, and make sure it still comes out
the same.

Reviewers: george.burgess.iv

Subscribers: llvm-commits

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

llvm-svn: 293356

llvm-svn: 293355

llvm-svn: 293354

In r292621, the recommit fixes a bug related with live interval update
after the partial redundent copy is moved.

This recommit solves an additional bug related to the lack of update of
subranges.

The original patch is to solve the performance problem described in
PR27827. Register coalescing sometimes cannot remove a copy because of
interference. But if we can find a reverse copy in one of the predecessor
block of the copy, the copy is partially redundent and we may remove the
copy partially by moving it to the predecessor block without the
reverse copy.

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

Re-apply r292621

Revert "Revert rL292621. Caused some internal build bot failures in apple."

This reverts commit r292984.

Original patch: Wei Mi <wmi@google.com>
Subrange fix: Mostly Matthias Braun <matze@braunis.de>

llvm-svn: 293353

This reverts commit r293283 because it broke MSVC build.

llvm-svn: 293352

    #0 0x89cdeb in operator new[](unsigned long) /code/llvm/projects/compiler-rt/lib/asan/asan_new_delete.cc:84:37
    #1 0x4ec87c4 in llvm::RegisterBankInfo::ValueMapping const* llvm::RegisterBankInfo::getOperandsMapping<llvm::RegisterBankInfo::ValueMapping const* const*>(llvm::RegisterBankInfo::ValueMapping const* const*, llvm::RegisterBankInfo::ValueMapping const* const*) const /code/llvm/lib/CodeGen/GlobalISel/RegisterBankInfo.cpp:297:9
    #2 0x9327ee in llvm::AArch64RegisterBankInfo::getInstrMapping(llvm::MachineInstr const&) const /code/llvm/lib/Target/AArch64/AArch64RegisterBankInfo.cpp:540:30
    #3 0x4eb8d07 in llvm::RegBankSelect::assignInstr(llvm::MachineInstr&) /code/llvm/lib/CodeGen/GlobalISel/RegBankSelect.cpp:546:24
    #4 0x4eb9dd2 in llvm::RegBankSelect::runOnMachineFunction(llvm::MachineFunction&) /code/llvm/lib/CodeGen/GlobalISel/RegBankSelect.cpp:624:12
    #5 0x3141875 in llvm::MachineFunctionPass::runOnFunction(llvm::Function&) /code/llvm/lib/CodeGen/MachineFunctionPass.cpp:62:13
    #6 0x396128d in llvm::FPPassManager::runOnFunction(llvm::Function&) /code/llvm/lib/IR/LegacyPassManager.cpp:1513:27
    #7 0x3961832 in llvm::FPPassManager::runOnModule(llvm::Module&) /code/llvm/lib/IR/LegacyPassManager.cpp:1534:16
    #8 0x3962540 in runOnModule /code/llvm/lib/IR/LegacyPassManager.cpp:1590:27
    #9 0x3962540 in llvm::legacy::PassManagerImpl::run(llvm::Module&) /code/llvm/lib/IR/LegacyPassManager.cpp:1693
    #10 0x8ae368 in compileModule(char**, llvm::LLVMContext&) /code/llvm/tools/llc/llc.cpp:562:8
    #11 0x8a7a1b in main /code/llvm/tools/llc/llc.cpp:316:22

llvm-svn: 293351