[InstCombine] regenerate checks

llvm-svn: 281186

[InstCombine] regenerate checks

llvm-svn: 281185

ADT: Never allocate nodes in iplist<> and ilist<>

Remove createNode() and any API that depending on it, and add
HasCreateNode to the list of checks for HasObsoleteCustomizations.  Now
an ilist *never* allocates (this was already true for iplist).

This factors out all the differences between iplist and ilist.  I'll aim
to rename both to "owning_ilist" eventually, to call out the interesting
(not exactly intrusive) ownership semantics.  In the meantime, I've left
both names around to reduce code churn.

One of the deleted APIs is the ilist copy constructor.  I've lifted up
and tested iplist::cloneFrom (ala simple_ilist::cloneFrom) as a
replacement.

Users of ilist<> and iplist<> that want the list to allocate nodes have
a few options:
- use std::list;
- use AllocatorList or BumpPtrList (or build a similarly trivial list);
- use cloneFrom (which is explicit at the call site); or
- allocate at the call site.

See r280573, r281177, r281181, and r281182 for examples of what to do if
you're updating out-of-tree code.

llvm-svn: 281184

ADT: Fix build after r281182

Fix this bot:
  http://lab.llvm.org:8011/builders/clang-x86_64-linux-abi-test/builds/20680

which complained that a typedef of 'iterator_adaptor_base' changed
meaning in AllocatorList::IteratorImpl.  Use 'base_type' there instead.

llvm-svn: 281183

ADT: Add AllocatorList, and use it for yaml::Token

- Add AllocatorList, a non-intrusive list that owns an LLVM-style
  allocator and provides a std::list-like interface (trivially built on
  top of simple_ilist),
- add a typedef (and unit tests) for BumpPtrList, and
- use BumpPtrList for the list of llvm::yaml::Token (i.e., TokenQueueT).

TokenQueueT has no need for the complexity of an intrusive list.  The
only reason to inherit from ilist was to customize the allocator.
TokenQueueT was the only example in-tree of using ilist<> in a truly
non-intrusive way.

Moreover, this removes the final use of the non-intrusive
ilist_traits<>::createNode (after r280573, r281177, and r281181).  I
have a WIP patch that removes this customization point (and the API that
relies on it) that I plan to commit soon.

Note: AllocatorList owns the allocator, which limits the viable API
(e.g., splicing must be on the same list).  For now I've left out
any problematic API.  It wouldn't be hard to split AllocatorList into
two layers: an Impl class that calls DerivedT::getAlloc (via CRTP), and
derived classes that handle Allocator ownership/reference/etc semantics;
and then implement splice with appropriate assertions; but TBH we should
probably just customize the std::list allocators at that point.

llvm-svn: 281182

Analysis: Only allow the move-constructor for IVUsers

Force IVUsers to be moved instead of copied, properly update Parent
pointers in IVStrideUse when IVUsers is moved, and make sure we have
move constructors available in iplist and ilist.

I came across this in a WIP patch that deleted the copy constructors
from ilist.  I was surprised to find that IVUsersAnalysis couldn't be
registered in the new pass manager.

It's not clear to me whether IVUsers was getting moved only when empty,
but if it was being moved when it was non-empty then this fixes a
pointer invalidation bug and should give some sort of speedup.  Note
that the bugfix would be necessary even for a copy constructor.

llvm-svn: 281181

[TwoAddressInstruction] When commuting an instruction don't assume that the destination register is operand 0. Pass it from the caller.

In practice it probably is 0 so this may not be a functional change.

llvm-svn: 281180

[libcxx] Introduce an externally-threaded libc++ variant.

This patch further decouples libc++ from pthread, allowing libc++ to be built
against other threading systems. There are two main use cases:

- Building libc++ against a thread library other than pthreads.

- Building libc++ with an "external" thread API, allowing a separate library to
  provide the implementation of that API.

The two use cases are quite similar, the second one being sligtly more
de-coupled than the first. The cmake option LIBCXX_HAS_EXTERNAL_THREAD_API
enables both kinds of builds. One needs to place an <__external_threading>
header file containing an implementation of the "libc++ thread API" declared
in the <__threading_support> header.

For the second use case, the implementation of the libc++ thread API can
delegate to a custom "external" thread API where the implementation of this
external API is provided in a seperate library. This mechanism allows toolchain
vendors to distribute a build of libc++ with a custom thread-porting-layer API
(which is the "external" API above), platform vendors (recipients of the
toolchain/libc++) are then required to provide their implementation of this API
to be linked with (end-user) C++ programs.

Note that the second use case still requires establishing the basic types that
get passed between the external thread library and the libc++ library
(e.g. __libcpp_mutex_t). These cannot be opaque pointer types (libc++ sources
won't compile otherwise). It should also be noted that the second use case can
have a slight performance penalty; as all the thread constructs need to cross a
library boundary through an additional function call.

When the header <__external_threading> is omitted, libc++ is built with the
"libc++ thread API" (declared in <__threading_support>) as the "external" thread
API (basic types are pthread based). An implementation (pthread based) of this
API is provided in test/support/external_threads.cpp, which is built into a
separate DSO and linked in when running the libc++ test suite. A test run
therefore demonstrates the second use case (less the intermediate custom API).

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

Reviewers: bcraig, compnerd, EricWF, mclow.lists
llvm-svn: 281179

[ORC] Update examples for header changes in r281171.

llvm-svn: 281178

ScalarOpts: Use std::list for Candidates, NFC

There is nothing intrusive about the Candidate list; use std::list over
llvm::ilist for simplicity.

llvm-svn: 281177

ScalarOpts: Sort includes, NFC

llvm-svn: 281176

ADT: Remove ilist_iterator::reset(), NFC

ilist_iterator::reset was unnecessary API, and wasn't any clearer (or
safer) at the call site than constructing a temporary and assigning it
to the iterator.

llvm-svn: 281175

[ORC] Fix the RPC unit test for header changes in r281171.

llvm-svn: 281173

CodeGen: Give MachineBasicBlock::reverse_iterator a handle to the current MI

Now that MachineBasicBlock::reverse_instr_iterator knows when it's at
the end (since r281168 and r281170), implement
MachineBasicBlock::reverse_iterator directly on top of an
ilist::reverse_iterator by adding an IsReverse template parameter to
MachineInstrBundleIterator.  This replaces another hard-to-reason-about
use of std::reverse_iterator on list iterators, matching the changes for
ilist::reverse_iterator from r280032 (see the "out of scope" section at
the end of that commit message).  MachineBasicBlock::reverse_iterator
now has a handle to the current node and has obvious invalidation
semantics.

r280032 has a more detailed explanation of how list-style reverse
iterators (invalidated when the pointed-at node is deleted) are
different from vector-style reverse iterators like std::reverse_iterator
(invalidated on every operation).  A great motivating example is this
commit's changes to lib/CodeGen/DeadMachineInstructionElim.cpp.

Note: If your out-of-tree backend deletes instructions while iterating
on a MachineBasicBlock::reverse_iterator or converts between
MachineBasicBlock::iterator and MachineBasicBlock::reverse_iterator,
you'll need to update your code in similar ways to r280032.  The
following table might help:

                  [Old]              ==>             [New]
        delete &*RI, RE = end()                   delete &*RI++
        RI->erase(), RE = end()                   RI++->erase()
      reverse_iterator(I)                 std::prev(I).getReverse()
      reverse_iterator(I)                          ++I.getReverse()
    --reverse_iterator(I)                            I.getReverse()
      reverse_iterator(std::next(I))                 I.getReverse()
                RI.base()                std::prev(RI).getReverse()
                RI.base()                         ++RI.getReverse()
              --RI.base()                           RI.getReverse()
     std::next(RI).base()                           RI.getReverse()

(For more details, have a look at r280032.)

llvm-svn: 281172

[ORC] Rename RPCChannel to RPCByteChannel. NFC.

llvm-svn: 281171

CodeGen: Assert that bundle iterators are valid

Add an assertion to the MachineInstrBundleIterator from instr_iterator
that the underlying iterator is valid.  This is possible know that we
can check ilist_node::isSentinel (since r281168), and is consistent with
the constructors from MachineInstr* and MachineInstr&.

Avoiding the new assertion in operator== and operator!= requires four
(!!!!) new overloads each.

(As an aside, I'm strongly in favour of:
- making the conversion from instr_iterator explicit;
- making the conversion from pointer explicit;
- making the conversion from reference explicit; and
- removing all the extra overloads of operator== and operator!= except
  const_instr_iterator.

I'm not signing up for that at this point, but being clear about when
something is an MachineInstr-iterator (possibly instr_end()) vs
MachineInstr-bundle-iterator (possibly end()) vs MachineInstr* (possibly
nullptr) vs MachineInstr& (known valid) would surely make code
cleaner... and it would remove a ton of boilerplate from
MachineInstrBundleIterator operators.)

llvm-svn: 281170

Fix the modules build after r281167

Add an #include for <type_traits> to llvm/ADT/ilist_node_options.h to
make it standalone.

llvm-svn: 281169

CodeGen: Turn on sentinel tracking for MachineInstr iterators

This is a prep commit before fixing MachineBasicBlock::reverse_iterator
invalidation semantics, ala r281167 for ilist::reverse_iterator.  This
changes MachineBasicBlock::Instructions to track which node is the
sentinel regardless of LLVM_ENABLE_ABI_BREAKING_CHECKS.

There's almost no functionality change (aside from ABI).  However, in
the rare configuration:

    #if !defined(NDEBUG) && !defined(LLVM_ENABLE_ABI_BREAKING_CHECKS)

the isKnownSentinel() assertions in ilist_iterator<>::operator* suddenly
have teeth for MachineInstr.  If these assertions start firing for your
out-of-tree backend, have a look at the suggestions in the commit
message for r279314, and at some of the commits leading up to it that
avoid dereferencing the end() iterator.

llvm-svn: 281168

ADT: Add sentinel tracking and custom tags to ilists

This adds two declarative configuration options for intrusive lists
(available for simple_ilist, iplist, and ilist).  Both of these options
affect ilist_node interoperability and need to be passed both to the
node and the list.  Instead of adding a new traits class, they're
specified as optional template parameters (in any order).

The two options:

 1. Pass ilist_sentinel_tracking<true> or ilist_sentinel_tracking<false>
    to control whether there's a bit on ilist_node "prev" pointer
    indicating whether it's the sentinel.  The default behaviour is to
    use a bit if and only if LLVM_ENABLE_ABI_BREAKING_CHECKS.

 2. Pass ilist_tag<TagA> and ilist_tag<TagB> to allow insertion of a
    single node into two different lists (simultaneously).

I have an immediate use-case for (1) ilist_sentinel_tracking: fixing the
validation semantics of MachineBasicBlock::reverse_iterator to match
ilist::reverse_iterator (ala r280032: see the comments at the end of the
commit message there).  I'm adding (2) ilist_tag in the same commit to
validate that the options framework supports expansion.  Justin Bogner
mentioned this might enable a possible cleanup in SelectionDAG, but I'll
leave this to others to explore.  In the meantime, the unit tests and
the comments for simple_ilist and ilist_node have usage examples.

Note that there's a layer of indirection to support optional,
out-of-order, template paramaters.  Internal classes are templated on an
instantiation of the non-variadic ilist_detail::node_options.
User-facing classes use ilist_detail::compute_node_options to compute
the correct instantiation of ilist_detail::node_options.

The comments for ilist_detail::is_valid_option describe how to add new
options (e.g., ilist_packed_int<int NumBits>).

llvm-svn: 281167

Add missing 'REQUIRES' line

llvm-svn: 281166

GPGPU: Do not fail in case of arrays never accessed

If these arrays have never been accessed we failed to derive an upper bound
of the accesses and consequently a size for the outermost dimension. We
now explicitly check for empty access sets and then just use zero as size
for the outermost dimension.

llvm-svn: 281165

[AVX512] Fix pattern for vgetmantsd and all other instructions that use same class. Fix memory operand size, remove unnecessary pattern.

Differential Revision: http://reviews.llvm.org/D24443

llvm-svn: 281164

Fixup failing debuginfo test for change in SimplifyCFG.

This reverts this test back to its original pre-r280364 behaviour as we don't sink allocas any more.

llvm-svn: 281163

[SimplifyCFG] Be even more conservative in SinkThenElseCodeToEnd

This should *actually* fix PR30244. This cranks up the workaround for PR30188 so that we never sink loads or stores of allocas.

The idea is that these should be removed by SROA/Mem2Reg, and any movement of them may well confuse SROA or just cause unwanted code churn. It's not ideal that the midend should be crippled like this, but that unwanted churn can really cause significant regressions in important workloads (tsan).

llvm-svn: 281162

[AArch64] Fixup test after r281160

How I missed this locally is beyond me. I suspect llc didn't recompile. This is just changing the CHECK line back to what it was before r280364.

llvm-svn: 281161

[SimplifyCFG] Harden up the profitability heuristic for block splitting during sinking

Exposed by PR30244, we will split a block currently if we think we can sink at least one instruction. However this isn't right - the reason we split predecessors is so that we can sink instructions that otherwise couldn't be sunk because it isn't safe to do so - stores, for example.

So, change the heuristic to only split if it thinks it can sink at least one non-speculatable instruction.

Should fix PR30244.

llvm-svn: 281160

GPURuntime: ensure compilation with C99

Otherwise, older compiler will error out on some of the C99 features we use.

llvm-svn: 281159

[CodeGen] Make the TwoAddressInstructionPass check if the instruction is commutable before calling findCommutedOpIndices for every operand. Also make sure the operand is a register before each call to save some work on commutable instructions that might have an operand.

llvm-svn: 281158

[AVX-512] Add test cases to demonstrate opportunities for commuting vpternlog. Commuting will be added in a future commit.

llvm-svn: 281157

[AVX-512] Add VPTERNLOG to load folding tables.

llvm-svn: 281156

[X86] Side effecting asm in AVX512 integer stack folding test should return 2 x i64 not 8 x i64.

llvm-svn: 281155

[X86] Make a helper method into a static function local to the cpp file.

llvm-svn: 281154

Add handling of !invariant.load to PropagateMetadata.

Summary:
This will let e.g. the load/store vectorizer propagate this metadata
appropriately.

Reviewers: arsenm

Subscribers: tra, jholewinski, hfinkel, mzolotukhin

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

llvm-svn: 281153

[NVPTX] Use ldg for explicitly invariant loads.

Summary:
With this change (plus some changes to prevent !invariant from being
clobbered within llvm), clang will be able to model the __ldg CUDA
builtin as an invariant load, rather than as a target-specific llvm
intrinsic.  This will let the optimizer play with these loads --
specifically, we should be able to vectorize them in the load-store
vectorizer.

Reviewers: tra

Subscribers: jholewinski, hfinkel, llvm-commits, chandlerc

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

llvm-svn: 281152

[CodeGen] Split out the notions of MI invariance and MI dereferenceability.

Summary:
An IR load can be invariant, dereferenceable, neither, or both.  But
currently, MI's notion of invariance is IR-invariant &&
IR-dereferenceable.

This patch splits up the notions of invariance and dereferenceability at
the MI level.  It's NFC, so adds some probably-unnecessary
"is-dereferenceable" checks, which we can remove later if desired.

Reviewers: chandlerc, tstellarAMD

Subscribers: jholewinski, arsenm, nemanjai, llvm-commits

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

llvm-svn: 281151

CodeGen: remove unnecessary else case

Refactor the assignment so that its much more clear that the if-clause contains
the lookup, and once cached is directly used.  NFC.

llvm-svn: 281150

MCInstrDesc: Flags (uint64_t) was checked using (1 << MCID::XYZ), but this
should have been (1ULL << MCID::XYZ). Currently this works because enum Flag
has 31 values, but extending it will result in a compile warnings/errors.
This was part of the accepted patch in https://reviews.llvm.org/D23601, but
it was suggested to apply this first as a separate patch.

llvm-svn: 281149

[MachO] Remove code accidentally cut'n'pasted 3 times.

It wasn't harmful, just goofy. It's weird to see how this has
fallen through the crack without anybody noticing for so long.

llvm-svn: 281148

It should also be legal to pass a swifterror parameter to a call as a swifterror
argument.

rdar://28233388

llvm-svn: 281147

[llvm-cov] Move the 'jump to first unexecuted line' link

Having it in the same row as the source name is jarring. Move it next to
the "Source" column label.

llvm-svn: 281146

[llvm-cov] Minor visual tweaks for html reports

  - Change the location of the 'Region Coverage' column.
  - Use less css and text for some labels.

llvm-svn: 281145

InstCombine: Don't combine loads/stores from swifterror to a new type

This generates invalid IR: the only users of swifterror can be call
arguments, loads, and stores.

rdar://28242257

llvm-svn: 281144

Add an isSwiftError predicate to Value

llvm-svn: 281143

ADT: Move ilist_node_access to ilist_detail::NodeAccess...

... and make a few ilist-internal API changes, in preparation for
changing how ilist_node is templated.  The only effect for ilist users
should be changing the friend target from llvm::ilist_node_access to
llvm::ilist_detail::NodeAccess (which is only necessary when they
inherit privately from ilist_node).
- Split out SpecificNodeAccess, which has overloads of getNodePtr and
  getValuePtr that are untemplated.
- Use more typedefs to prevent more changes later.
- Force inheritance to use *NodeAccess (to emphasize that ilist *users*
  shouldn't be doing this).

There should be no functionality change here.

llvm-svn: 281142

ADT: Use typedefs for ilist_base and ilist_node_base, NFC

This is a prep commit to minimize changes in a follow-up that is adding
a template parameter to ilist_node_base and ilist_base.

llvm-svn: 281141

[InstCombine] clean up foldICmpBinOpEqualityWithConstant / foldICmpIntrinsicWithConstant ; NFC

1. Rename variables to be consistent with related/preceding code (may want to reorganize).
2. Fix comments/formatting.

llvm-svn: 281140

[InstCombine] rename and reorganize some icmp folding functions; NFC

Everything under foldICmpInstWithConstant() should now be working for
splat vectors via m_APInt matchers. Ie, I've removed all of the FIXMEs
that I added while cleaning that section up. Note that not all of the
associated FIXMEs in the regression tests are gone though, because some
of the tests require earlier folds that are still scalar-only.

llvm-svn: 281139

We also need to pass swifterror in R12 under swiftcc not only under ccc

rdar://28190687

llvm-svn: 281138

[AMDGPU] Refactor MUBUF/MTBUF instructions

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

llvm-svn: 281137

Add missing test coverage for an inheritance model attrib merge diag.

Without this, no tests fail if I remove the Diag() in the first if in
Sema::mergeMSInheritanceAttr().

llvm-svn: 281136

[gold/LTO] Add test case for r281134

Add test case that was supposed to go in with r281134.

llvm-svn: 281135

[LTO] Handle null GV in Symbol object

Similar to other Symbol methods, have Symbol::getComdat handle
a null GV gracefully.

Fixes PR30326.

llvm-svn: 281134

[tablegen] Check that an optional IdentifierArgument of an attribute is
provided before trying to print it.

This fixes a segfault that occurs when function printPretty generated by
tablegen tries to print an optional argument of attribute
objc_bridge_related.

rdar://problem/28155469

llvm-svn: 281132

[WebAssembly] Fix typos in comments

llvm-svn: 281131

[libFuzzer] print a failed-merge warning only in the merge mode

llvm-svn: 281130

[ELF] Fix memory leak in BinaryFile handling.

llvm-svn: 281129

AMDGPU: Implement is{LoadFrom|StoreTo}FrameIndex

llvm-svn: 281128

AMDGPU: Fix scheduling info for spill pseudos

These defaulted to Write32Bit. I don't think this actually matters
since these don't exist during scheduling.

llvm-svn: 281127

[asan] Add flag to allow lifetime analysis of problematic allocas

Summary:
Could be useful for comparison when we suspect that alloca was skipped
because of this.

Reviewers: eugenis

Subscribers: llvm-commits

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

llvm-svn: 281126

[CodeGen] Rename MachineInstr::isInvariantLoad to isDereferenceableInvariantLoad.  NFC

Summary:
I want to separate out the notions of invariance and dereferenceability
at the MI level, so that they correspond to the equivalent concepts at
the IR level.  (Currently an MI load is MI-invariant iff it's
IR-invariant and IR-dereferenceable.)

First step is renaming this function.

Reviewers: chandlerc

Subscribers: MatzeB, jfb, llvm-commits

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

llvm-svn: 281125

[libFuzzer] don't print help for internal flags

llvm-svn: 281124

[libFuzzer] print a visible message if merge fails due to a crash

llvm-svn: 281122

async structured data packet handling improvements

This change does the following:
* Changes the signature for the continuation delegate method that handles
  async structured data from accepting an already-parsed structured data
  element to taking just the packet contents.
* Moves the conversion of the JSON-async: packet contents from
  GDBRemoteClientBase to the continuation delegate method.
* Adds a new unit test for verifying that the $JSON-asyc: packets get
  decoded and that the decoded packets get forwarded on to the delegate
  for further processing. Thanks to Pavel for making that whole section of
  code easily unit testable!
* Tightens up the packet verification on reception of a $JSON-async:
  packet contents. The code prior to this change is susceptible to a
  segfault if a packet is carefully crafted that starts with $J but
  has a total length shorter than the length of "$JSON-async:".

Reviewers: labath, clayborg, zturner

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

llvm-svn: 281121

Remove dead code in the SelectionDAG headers (NFC)

I tested this with "ninja check-llvm-codegen" on a Release build with
all architectures enabled, and again with a Debug build on x86.

Found with llvm-cov.

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

llvm-svn: 281120

Modules: for ObjectiveC try to keep the definition invariant.

When deserializing ObjCInterfaceDecl with definition data, if we already have
a definition, try to keep the definition invariant; also pull in the
categories even if it is not what getDefinition returns (this effectively
combines categories).

rdar://27926200
rdar://26708823

llvm-svn: 281119

[SE] Remove Utils directory

Summary:
There is no purpose in splitting out the Error class from the rest of
the StreamExecutor code. This organization was just a vestige of an old
failed design.

Plus, this change fixes a bug in the build where the utilites library
was not being statically linked in with libstreamexecutor.

Reviewers: jlebar, jprice

Subscribers: beanz, parallel_libs-commits

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

llvm-svn: 281118

AMDGPU: Fix immediate folding logic when shrinking instructions

If the literal is being folded into src0, it doesn't matter
if it's an SGPR because it's being replaced with the literal.

Also fixes initially selecting 32-bit versions of some instructions
which also confused commuting.

llvm-svn: 281117

[sanitizer] Add interceptor for ttyname_r

Reviewers: eugenis

Subscribers: kubabrecka, llvm-commits

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

llvm-svn: 281116

Move the contents of test/elf to test/ELF

Having two directories with the same name modulo case does not work well
on Windows. The new test/elf directory was added in r281108. I assume
the intention was to add the test file to the existing test/ELF dir.

llvm-svn: 281115

Inliner: Don't mark swifterror allocas with lifetime markers

This would create a bitcast use which fails the verifier: swifterror values may
only be used by loads, stores, and as function arguments.

rdar://28233244

llvm-svn: 281114

X86: Fold tail calls into conditional branches also for 64-bit (PR26302)

This extends the optimization in r280832 to also work for 64-bit. The only
quirk is that we can't do this for 64-bit Windows (yet).

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

llvm-svn: 281113

AMDGPU: Run LoadStoreVectorizer pass by default

llvm-svn: 281112

[libFuzzer] use sizeof() in tests instead of 4 and 8

llvm-svn: 281111

LSV: Fix incorrectly increasing alignment

If the unaligned access has a dynamic offset, it may be odd which
would make the adjusted alignment incorrect to use.

llvm-svn: 281110

[gold] Test that we handle invalid directory correctly.

I had this test sitting around for a while but always forgot to
commit. Rafael reviewed it a while ago.

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

llvm-svn: 281109

[ELF] Add support for -b binary

Implemented by building an ELF file in memory.

elf, default, and binary match gold behavior.

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

llvm-svn: 281108

[InstCombine] use m_APInt to allow icmp ult X, C folds for splat constant vectors

llvm-svn: 281107

[libFuzzer] one more puzzle for value profile

llvm-svn: 281106

[X86][XOP] Fix VPERMIL2PD mask creation on 32-bit targets

Use getConstVector helper to correctly create v2i64/v4i64 constants on 32-bit targets

llvm-svn: 281105

[Hexagon] Fix disassembler crash after r279255

When p0 was added as an explicit operand to the duplex subinstructions,
the disassembler was not updated to reflect this.

llvm-svn: 281104

[sanitizer] fix an allocator bug where the allocated memory may overlap with the free array (kudos to Kostya Korcthinsky). Also make sure that the allocator does not mmap more than requested. Test both.

llvm-svn: 281103

[X86] Regenerate test. NFC.

llvm-svn: 281099

Add comments.

llvm-svn: 281098

Enable in-tree builds of parallel-libs.

Summary:
parallel-libs needs its own changes to make this work; these are just
the LLVM changes.

Reviewers: jhen

Subscribers: llvm-commits, beanz, jprice

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

llvm-svn: 281097

Revert "Compact InputSectionData from 64 to 48 bytes. NFC."

This reverts commit r281084.

The link was failing on some bots. No idea why. I will try to
reproduce it on Monday.

llvm-svn: 281096

Create phi nodes for swifterror values at the end of the phi instructions list

ISel makes assumption about the order of phi nodes.

rdar://28190150

llvm-svn: 281095

Debug info: Bump the default DWARF version on Darwin to 4.

This is a spiritual re-commit of r201375 with only a brief delay
for upgrading the green dragon builders.

llvm-svn: 281094

[asan] Store access_size in the {Stack,Global}AddressDescription objects

Summary:
This is important information when we want to describe errors, and should be
part of these descriptions. Otherwise, we need to know the access size when
printing/emitting the description.

Reviewers: kcc, eugenis, vitalybuka

Subscribers: llvm-commits, kubabrecka

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

llvm-svn: 281093

[NVPTX] Implement llvm.fabs.f32, llvm.max.f32, etc.

Summary:
Previously these only worked via NVPTX-specific intrinsics.

This change will allow us to convert these target-specific intrinsics
into the general LLVM versions, allowing existing LLVM passes to reason
about their behavior.

It also gets us some minor codegen improvements as-is, from situations
where we canonicalize code into one of these llvm intrinsics.

Reviewers: majnemer

Subscribers: llvm-commits, jholewinski, tra

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

llvm-svn: 281092

[StreamExecutor] Make SE work with an in-tree LLVM build.

Summary:
With these changes, we can put parallel-libs within llvm/projects and
build as normal.

This is kind of the minimal change I could figure out how to make while
still making us compatible with llvm's build system.  Some things I'm
not thrilled about include:

 * The creation of a CoreTests directory (the macros really seemed to
   want this)

 * Pulling SimpleHostPlatformDevice.h into CoreTests.  It seems to me
   this should live inside unittests/include, or maybe tests/include,
   but I didn't want to make that change in this patch.

One important piece of work that remains to be done is to make

  $ ninja check-streamexecutor

run all the tests.  Right now the only way I've figured out to run the
tests is

  $ ninja projects/parallel-libs/streamexecutor/unittests/StreamExecutorUnitTests
  $ projects/parallel-libs/streamexecutor/unittests/CoreTests/CoreTests

Reviewers: jhen

Subscribers: beanz, parallel_libs-commits, jprice

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

llvm-svn: 281091

[asan] Add a new AddressDescription structure, which can describe any type of address.

Summary:
This is useful for inclusion in the Error* structures, to describe an
arbitrary address.

Remove the old struct since it's used only once. This removes one level of
indirection, and moves all *AddressDescription to be one of the recently
introduced structures.

This merges differential revisions: D24131 and D24132

Reviewers: kcc, eugenis, vitalybuka

Subscribers: kubabrecka, llvm-commits

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

llvm-svn: 281090

[CUDA] Make __GCC_ATOMIC_XXX_LOCK_FREE macros the same on host/device.

Summary:
This fixes a bug where we were unable to compile the following CUDA
file with libstdc++ (didn't try libc++):

  #include <future>
  void foo() { std::shared_future<int> x; }

The problem is that <future> only defines std::shared_future if
__GCC_ATOMIC_INT_LOCK_FREE > 1.  When we compiled this file for device,
the macro was set to 1, and then the class didn't exist at all.

Reviewers: tra

Subscribers: cfe-commits, jhen

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

llvm-svn: 281089

ARM: move the builtins libcall CC setup

Move the target specific setup into the target specific lowering setup.  As
pointed out by Anton, the initial change was moving this too high up the stack
resulting in a violation of the layering (the target generic code path setup
target specific bits).  Sink this into the ARM specific setup.  NFC.

llvm-svn: 281088

[cmake] Fix a stale comment from an earlier version of r281085. NFC.

llvm-svn: 281086

[cmake] Export gtest/gtest_main and its dependencies via a special build tree only cmake exports file.

Previously, gtest/gtest_main were not exported via cmake. The intention here was
to ensure that users whom are linking against the LLVM install tree would not
get the gtest/gtest_main targets. This prevents downstream projects that link
against the LLVM build tree (i.e. Swift) from getting this dependency
information in their cmake builds. Without such dependency information, linker
issues can result on linux due to LLVMSupport being put before gtest on the
linker command line.

This commit preserves behavior that we want for the install tree, while adding
support for the build tree by:

1. The special casing for gtest/gtest_main in the add_llvm_library code is
removed in favor of a flag called "BUILDTREE_ONLY". If this is set, then the
library is communicating that it is only meant to be exported into the build
tree and is not meant to be installed or exported via the install tree. This
part is just a tweak to remove the special case, the underlying code is the
same.

2. The cmake code that exports cmake targets for the build tree has special code
to import an additional targets file called
LLVMBuildTreeOnlyExports.cmake. Additionally the extra targets are added to the
LLVMConfig.cmake's LLVM_EXPORTED_TARGETS variable. In contrast, the
"installation" cmake file uses the normal LLVM_EXPORTS_TARGETS as before and
does not include the extra exports file. This is implemented by
defining/undefining variables when performing a configure of the build/install
tree LLVMConfig.cmake files.

llvm-svn: 281085

Compact InputSectionData from 64 to 48 bytes. NFC.

llvm-svn: 281084

test: adjust the GUID

Although the GUID seems to be stable across test runs now, it seems to be
unstable across hosts.  Lets be a bit more lax about the reading of the RSDS
record.

llvm-svn: 281083

Add a lower level zlib::uncompress.

SmallVectors are convenient, but they don't cover every use case.

In particular, they are fairly large (3 pointers + one element) and
there is no way to take ownership of the buffer to put it somewhere
else.  This patch then adds a lower lever interface that works with
any buffer.

llvm-svn: 281082

AMDGPU : Fix mqsad_u32_u8 instruction incorrect data type.

Differential Revision: http://reviews.llvm.org/D23700

llvm-svn: 281081

AMDGPU/SI: Make sure llvm.amdgcn.implicitarg.ptr() is 8-byte aligned for HSA

Reviewers: arsenm

Subscribers: arsenm, wdng, nhaehnle, llvm-commits

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

llvm-svn: 281080