llvm-svn: 243910

Various value handles needed to be copy constructible and copy
assignable (mostly for their use in DenseMap). But to avoid an API that
might allow accidental slicing, make these members protected in the base
class and make derived classes final (the special members become
implicitly public there - but disallowing further derived classes that
might be sliced to the intermediate type).

Might be worth having a warning a bit like -Wnon-virtual-dtor that
catches public move/copy assign/ctors in classes with virtual functions.
(suppressable in the same way - by making them protected in the base,
and making the derived classes final) Could be fancier and only diagnose
them when they're actually called, potentially.

Also allow a few default implementations where custom implementations
(especially with non-standard return types) were implemented.

llvm-svn: 243909

This adds the required target feature names to x86 builtins that need
particular features. Most have exactly one ("avx", "aes", etc), but some
of the avx512 features have multiple requirements, eg "avx512vl,avx512bw".

llvm-svn: 243908

llvm-svn: 243907

"this namespace alias decl is unused" -> "namespace alias decl '...' is unused"

llvm-svn: 243906

llvm-svn: 243905

Fixes obvious memory leak in test
TestForEofAfterReadFailureOnDataStreamer.  Also removes constexpr use
from same test.

Patch by Karl Schimpf.

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

llvm-svn: 243904

llvm-svn: 243903

llvm-svn: 243902

(Because, hey, who wouldn't?)

llvm-svn: 243901

through PHI nodes across iterations.

This patch teaches the new advanced loop unrolling heuristics to propagate
constants into the loop from the preheader and around the backedge after
simulating each iteration. This lets us brute force solve simple recurrances
that aren't modeled effectively by SCEV. It also makes it more clear why we
need to process the loop in-order rather than bottom-up which might otherwise
make much more sense (for example, for DCE).

This came out of an attempt I'm making to develop a principled way to account
for dead code in the unroll estimation. When I implemented
a forward-propagating version of that it produced incorrect results due to
failing to propagate *cost* between loop iterations through the PHI nodes, and
it occured to me we really should at least propagate simplifications across
those edges, and it is quite easy thanks to the loop being in canonical and
LCSSA form.

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

llvm-svn: 243900

llvm-svn: 243899

While checking for the existence of the clang-tools-extra directory,
the script was not checking for its destination name, "extra", and
the script was failing when re-running without checking out new
sources.

llvm-svn: 243898

Some functions return concrete ByteStreamers by value - explicitly
support that in the base class. (dtor can be virtual, no one seems to be
polymorphically owning/destroying them)

llvm-svn: 243897

Recommit r243824: -Wdeprecated-clean: Fix cases of violating the rule of 5 in ways that are deprecated in C++11

This reverts commit r243888, recommitting r243824.

This broke the Windows build due to a difference in the C++ standard
library implementation. Using emplace/forward_as_tuple should ensure
there's no need to copy ValIDs.

llvm-svn: 243896

Summary:
This is consistent with binutils and ASan behavior on other platforms,
and makes it easier to use llvm-symbolizer with WinASan. The
--relative-address flag to llvm-symbolizer is also no longer needed.

An RVA is a "relative virtual address", meaning it is the address of
something inside the image minus the base of the mapping at runtime.

A VA in this context is an RVA plus the "preferred base" of the module,
and not a real runtime address. The real runtime address of a symbol
will equal the VA iff the module is loaded at its preferred base at
runtime.

On Windows, the preferred base is stored in the ImageBase field of one
of the PE file header, and this change adds the necessary code to
extract it. On Linux, this offset is typically included in program and
section headers of executables.

ELF shared objects typically use a preferred base of zero, meaning the
smallest p_vaddr field in the program headers is zero. This makes it so
that PIC and PIE module offsets come out looking like RVAs, but they're
actually VAs. The difference between them simply happens to be zero.

Reviewers: samsonov, majnemer

Subscribers: llvm-commits

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

llvm-svn: 243895

Also converted a cast<> to dyn_cast while i was working on the same
line of code.

llvm-svn: 243894

llvm-svn: 243893

Thanks to Aaron Ballman for spotting this.

llvm-svn: 243891

This fixes a bug found while working on the bitcode reader. In
particular, the method BitstreamReader::AtEndOfStream doesn't always
behave correctly when processing a data streamer. The method
fillCurWord doesn't properly set CurWord/BitsInCurWord if the data
streamer was already at eof, but GetBytes had not yet set the
ObjectSize field of the streaming memory object.

This patch fixes this problem, and provides a test to show that
this problem has been fixed.

Patch by Karl Schimpf.

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

llvm-svn: 243890

llvm-svn: 243889

Revert "-Wdeprecated-clean: Fix cases of violating the rule of 5 in ways that are deprecated in C++11"

This reverts commit r243824.

It broke the build on Windows.

llvm-svn: 243888

llvm-svn: 243887

Since r241097, `DIBuilder` has only created distinct `DICompileUnit`s.
The backend is liable to start relying on that (if it hasn't already),
so make uniquable `DICompileUnit`s illegal and automatically upgrade old
bitcode.  This is a nice cleanup, since we can remove an unnecessary
`DenseSet` (and the associated uniquing info) from `LLVMContextImpl`.

Almost all the testcases were updated with this script:

    git grep -e '= !DICompileUnit' -l -- test |
    grep -v test/Bitcode |
    xargs sed -i '' -e 's,= !DICompileUnit,= distinct !DICompileUnit,'

I imagine something similar should work for out-of-tree testcases.

llvm-svn: 243885

This is necessary for WatchOS support, where the compact unwind format assumes
this kind of layout. For now we only want this on Swift-like CPUs though, where
it's been the Xcode behaviour for ages. Also, since it can expand the prologue
we don't want it at -Oz.

llvm-svn: 243884

Instead of cloning distinct `MDNode`s when linking in a module, just
move them over.  The module linker destroys the source module, so the
old node would otherwise just be leaked on the context.  Create the new
node in place.  This also reduces the number of cloned uniqued nodes
(since it's less likely their operands have changed).

This mapping strategy is only correct when we're discarding the source,
so the linker turns it on via a ValueMapper flag, `RF_MoveDistinctMDs`.

There's nothing observable in terms of `llvm-link` output here: the
linked module should be semantically identical.

I'll be adding more 'distinct' nodes to the debug info metadata graph in
order to break uniquing cycles, so the benefits of this will partly come
in future commits.  However, we should get some gains immediately, since
we have a fair number of 'distinct' `DILocation`s being linked in.

llvm-svn: 243883

If set, this option instructs -view-scops and -polly-show to only print
functions that contain the specified string in their name. This allows to
look at the scops of a specific function in a large .ll file, without flooding
the screen with .dot graphs.

llvm-svn: 243882

Instead of always showing/printing all functions, a class derived from
the DOTViewer class can overwrite the set of functions that will be
processed.

This will be used (and tested) by Polly's scop viewers, but other users
can be imagined as well.

llvm-svn: 243881

Summary:
This is useful for PNaCl's `RewriteAtomics` pass. NaCl intrinsics don't exist for some of the more exotic RMW instructions, so by refactoring this function into its own, `RewriteAtomics` can share code rewriting those atomics with `AtomicExpand` while additionally saving a few cycles by generating the `cmpxchg` NaCl-specific intrinsic with the callback. Without this patch, `RewriteAtomics` would require two extra passes over functions, by first requiring use of the full `AtomicExpand` pass to just expand the leftover exotic RMWs and then running itself again to expand resulting `cmpxchg`s.

NFC

Reviewers: jfb

Subscribers: jfb, llvm-commits

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

llvm-svn: 243880

We currently have a dyld check in DyldNeedsEnvVariable that detects whether we are on a new OS X (10.11+) where we don't need to re-exec. For iOS simulator, we have a dlsym() hack that checks for a specific symbol, but this turns out to be fragile and problematic, because dlsym can sometimes call malloc(), which is not a good idea this early in the process runtime.

Let's instead of this do a direct comparison of dyld's version, which is exported in a public symbol `dyldVersionNumber`.

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

llvm-svn: 243879

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

llvm-svn: 243878

Currently string attributes on function arguments/return values can be generated using LLVM API. However they are not supported in parser. So, the following scenario will fail:
* generate function with string attribute using API,
* dump it in LL format,
* try to parse.
Add parser support for string attributes to fix the issue.

Reviewed By: reames, hfinkel

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

llvm-svn: 243877

Summary: Add IsConcept bit to VarDecl::NonParmVarDeclBitfields and associated isConcept/setConcept member functions. Set IsConcept to true when 'concept' specifier is in variable declaration. Create diagnostic when variable concept is not initialized.

Reviewers: fraggamuffin, hubert.reinterpretcast, faisalv, aaron.ballman, rsmith

Subscribers: aemerson, cfe-commits

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

llvm-svn: 243876

Summary:
Modify the cost calculation function for interleaved accesses
to use the target-specific costs for insert/extract element and
memory operations.

This better models the case where the backend can't match
the interleaved group, and we are forced to use a wide load
and shuffle vectors.

Interleaved accesses are not enabled by default, so this shouldn't
cause a performance change.

Reviewers: jmolloy

Subscribers: jmolloy, llvm-commits

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

llvm-svn: 243875

Enabling merging of extern globals appears to be generally either beneficial or
harmless. On some benchmarks suites (on Cortex-M4F, Cortex-A9, and Cortex-A57)
it gives improvements in the 1-5% range, but in the rest the overall effect is
zero.

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

llvm-svn: 243874

Adjust the GlobalMergeOnExternal option so that the default behaviour is to
do whatever the Target thinks is best. Explicitly enabled or disabling the
option will override this default.

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

llvm-svn: 243873

The test/DebugInfo/dwarfdump-macho-universal.test test added in r243862 uses
an input from another test's directory (test/tools/dsymutil/Inputs/fat-test.o)
which breaks our test setup.

Copying the required test input to the test's Input directory to fix the issue.

llvm-svn: 243872

commit review.

llvm-svn: 243871

Compiler crashed when vector elements / global register vars were used in inline assembler with "m" restriction. This patch fixes this.

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

llvm-svn: 243870

In http://reviews.llvm.org/rL215382, IT forming was made more conservative under
the belief that a flag-setting instruction was unpredictable inside an IT block on ARMv6M.

But actually, ARMv6M doesn't even support IT blocks so that's impossible. In the ARMARM for
v7M, v7AR and v8AR it states that the semantics of such an instruction changes inside an
IT block - it doesn't set the flags. So actually it is fine to use one inside an IT block
as long as the flags register is dead afterwards.

This gives significant performance improvements in a variety of MPEG based workloads.

Differential revision: http://reviews.llvm.org/D11680

llvm-svn: 243869