clang-tools-extra/test/clang-tidy/misc-move-forwarding-reference.cpp: Appease ms targets with -fno-delayed-template-parsing.

llvm-svn: 280078

[clang-tidy] Add check 'misc-move-forwarding-reference'

Summary:
The check emits a warning if std::move() is applied to a forwarding reference, i.e. an rvalue reference of a function template argument type.

If a developer is unaware of the special rules for template argument deduction on forwarding references, it will seem reasonable to apply std::move() to the forwarding reference, in the same way that this would be done for a "normal" rvalue reference.

This has a consequence that is usually unwanted and possibly surprising: If the function that takes the forwarding reference as its parameter is called with an lvalue, that lvalue will be moved from (and hence placed into an indeterminate state) even though no std::move() was applied to the lvalue at the callsite.

As a fix, the check will suggest replacing the std::move() with a std::forward().

This patch requires D23004 to be submitted before it.

Reviewers: sbenza, aaron.ballman

Subscribers: klimek, etienneb, alexfh, aaron.ballman, Prazek, Eugene.Zelenko, mgehre, cfe-commits

Projects: #clang-tools-extra

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

llvm-svn: 280077

www: Add links to Polly Labs and Polyhedral.info

llvm-svn: 280076

SILoadStoreOptimizer.cpp: Fix a warning in r279991. [-Wunused-variable]

llvm-svn: 280075

Fix fallout from the GetNameColonValue() refactor (r280000)

This fixes the linux test suite.

llvm-svn: 280074

[SimplifyCFG] Properly CSE metadata in SinkThenElseCodeToEnd

This was missing, meaning the metadata in sunk instructions was potentially bogus and could cause miscompiles.

llvm-svn: 280072

docs: mention that clobbering output regs in inline asm is illegal.

I've found this out the hard way; LLVM will not normally catch this
error (unless -verify-machineinstrs is passed), and under certain
very specific circumstances (such as register scavenger running
under pressure) this would result in an opaque crash in codegen.

llvm-svn: 280071

[ELF] - Linkerscript: implemented ADDR command.

ADDR(section)
Return the absolute address (the VMA) of the named section.

Used in the wild, eg.: https://searchcode.com/file/53617342/arch/x86/kernel/vmlinux.lds.S

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

llvm-svn: 280070

[ELF] - Fix for: bug 29115 - linkerscript does not support non-wildcard filename spec.

FreeBSD/mips script has non-wildcard filename specifications:
.text :
{
 start.o(.text*)

Patch adds support for that, this is PR29115.

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

llvm-svn: 280069

[ELF] - Use early return. NFC.

This addresses forgotten review comment for r280067:
"[ELF] - Versionscript: support wildcards for extern "c++" tag."

llvm-svn: 280068

[ELF] - Versionscript: support wildcards for extern "c++" tag.

Previously for extern keyword only names in quotes (exact match) was supported.
Patch adds support for wildcards, so next scripts can be handled properly:

LIBSAMPLE_1.0 {
   global:
     extern "C++" {
       foo*;
   };
 };

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

llvm-svn: 280067

[ELF] - Cleanup of scanVersionScript(): do not change local Demangled variable. NFC.

llvm-svn: 280066

Fix for commit 280064 that break the build.

llvm-svn: 280065

This adds new options -fdenormal-fp-math and passes through option -ffast-math
to CC1, which are translated to function attributes and can e.g. be mapped on
build attributes FP_exceptions and FP_denormal. Setting these build attributes
allows better selection of floating point libraries.

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

llvm-svn: 280064

clang-rename: fix formatting in USRFinder

As detected by clang-format.

llvm-svn: 280063

clang-rename: improve error message when -old-name is used and could not find symbol

Old output was:

clang-rename: could not find symbol at tools/clang/tools/extra/test/clang-rename/ClassFindByName.cpp:1:1 (offset 0).

Reviewers: omtcyfz

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

llvm-svn: 280062

[llvm-cov] Use the native path in the coverage report.

The coverage reports contain the source or binary file paths. On Windows,
the file path might contain the seperators of both '/' and '\'. This patch
uses the native path in the coverage reports. For example, on Windows,
all '/' are converted to '\'.

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

llvm-svn: 280061

www: Add IMPACT 2017 announcement to news page

llvm-svn: 280060

[Support][Error] Suppress warning about unused result.

llvm-svn: 280059

[Support] Add a conditionally defined default constructor (available on MSVC
only) for Expected<T> so that it can interoperate with MSVC's std::future
implementation.

MSVC 2013's std::future implementation requires the wrapped type to be default
constructible.

Hopefully this will fix the bot breakage in
http://lab.llvm.org:8011/builders/clang-x86-win2008-selfhost/builds/9937 .

llvm-svn: 280058

Combine two FileCheck patterns to prevent overzealous matching of .*

llvm-svn: 280057

Replace incorrect "#ifdef DEBUG" with "#ifndef NDEBUG".

The former is simply wrong -- the code will either never be used or will
always be used, rather than being dependent upon whether it's built with
debug assertions enabled.

The macro DEBUG isn't ever set by the llvm build system. But, the macro
DEBUG(X) is defined (unconditionally) if you happen to include
llvm/Support/Debug.h.

The code in Value.h which was erroneously protected by the #ifdef DEBUG
didn't even compile -- you can't cast<> from an LLVMOpaqueValue
directly. Fortunately, it was never invoked, as Core.cpp included
Value.h before Debug.h.

The conditionalized code in AArch64CollectLOH.cpp was previously always
used, as it includes Debug.h.

llvm-svn: 280056

[asan] Mark failing test as UNSUPPORTED.

llvm-svn: 280055

[libFuzzer] use bits instead of bytes for memcmp/strcmp value profile -- the fuzzer reaches the goal much faster, at least on the simple puzzles

llvm-svn: 280054

[PowerPC] Update the DWARF register-size table

The PPC64 DWARF register-size table did not match the ABI specification (or
GCC, for that matter). Fix that, and add a regression test.

Fixes PR27931.

llvm-svn: 280053

[RewriteStatepointsForGC] Update comment for same PHI node check. NFC

llvm-svn: 280052

[ORC][RPC] Reword 'async' to 'non-blocking' to better reflect call primitive
behaviors, and add a callB (blacking call) primitive.

callB is a blocking call primitive for threaded code where the RPC responses are
being processed on a separate thread. (For single threaded code callST should
continue to be used instead).

No unit test yet: Last time I commited a threaded unit test it deadlocked on
one of the s390x builders. I'll try to re-enable that test first, and add a new
test if I can sort out the deadlock issue.

llvm-svn: 280051

Add "FLAKY_TEST" test directive to support re-running flaky tests.

Some of the mutex tests fail on machines with high load. This patch implements
the test directive "// FLAKY_TEST" which allows a test to be run 3 times
before it's considered a failure.

llvm-svn: 280050

[PowerPC] Force entry alignment in .got2

Implement Bill's suggested fix for 32-bit targets for PR22711 (for the
alignment of each entry). As pointed out in the bug report, we could just force
the section alignment, since we only add pointer-sized things currently, but
this fix is somewhat more future-proof.

llvm-svn: 280049

Fix coding style; NFC

Avoid variables starting with lowercase.

llvm-svn: 280048

ADT: Explode include/llvm/ADT/{ilist,ilist_node}.h, NFC

I'm working on a lower-level intrusive list that can be used
stand-alone, and splitting the files up a bit will make the code easier
to organize.  Explode the ilist headers in advance to improve blame
lists in the future.
- Move ilist_node_base from ilist_node.h to ilist_node_base.h.
- Move ilist_base from ilist.h to ilist_base.h.
- Move ilist_iterator from ilist.h to ilist_iterator.h.
- Move ilist_node_access from ilist.h to ilist_node.h to support
  ilist_iterator.
- Update unit tests to #include smaller headers.
- Clang-format the moved things.

I noticed in transit that there is a simplify_type specialization for
ilist_iterator.  Since there is no longer an implicit conversion from
ilist<T>::iterator to T*, this doesn't make sense (effectively it's a
form of implicit conversion).  For now I've added a FIXME.

llvm-svn: 280047

[libFuzzer] use trace-div and trace-gep for guided fuzzing, add tests

llvm-svn: 280046

[sanitizer-coverage] add two more modes of instrumentation: trace-div and trace-gep, mostly usaful for value-profile-based fuzzing; run-time part

llvm-svn: 280045

[sanitizer-coverage] add two more modes of instrumentation: trace-div and trace-gep, mostly usaful for value-profile-based fuzzing; clang part

llvm-svn: 280044

[sanitizer-coverage] add two more modes of instrumentation: trace-div and trace-gep, mostly usaful for value-profile-based fuzzing; llvm part

llvm-svn: 280043

Fix syntax error in recent CMake change.

llvm-svn: 280042

[PowerPC] Add support for -mlongcall

Add support for GCC's PowerPC -mlongcall option; the backend supports the
corresponding target feature as of r280040.

Fixes PR19098.

llvm-svn: 280041

[PowerPC] Add support for -mlongcall

The "long call" option forces the use of the indirect calling sequence for all
calls (even those that don't really need it). GCC provides this option; This is
helpful, under certain circumstances, for building very-large binaries, and
some other specialized use cases.

Fixes PR19098.

llvm-svn: 280040

Update debugserver project to pull in StdStringExtractor.cpp instead of the new
llvm-using StringExtractor.cpp in the xcode project file settings.

llvm-svn: 280039

[asan] Disable test on darwin bot

According logs asan detects the bug but string with file name is not found.
I will investigate and fix the test.

llvm-svn: 280038

Fix PR28831 - Bad logic around CMAKE_OSX_SYSROOT and CMAKE_OSX_ARCHITECTURES.

See https://llvm.org/bugs/show_bug.cgi?id=28831 for more information about
the changes.

llvm-svn: 280037

NFC: add early exit in ModuleSummaryAnalysis

Summary:
Changed this code because it was not very readable.
The one question that I got after changing it is, should we
count calls to intrinsics? We don't add them to caller summary,
so maybe we shouldn't also count them?

Reviewers: tejohnson, eraman, mehdi_amini

Subscribers: llvm-commits

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

llvm-svn: 280036

C++ Modules TS: driver support for building modules.

This works as follows: we add --precompile to the existing gamut of options for
specifying how far to go when compiling an input (-E, -c, -S, etc.). This flag
specifies that an input is taken to the precompilation step and no further, and
this can be specified when building a .pcm from a module interface or when
building a .pch from a header file.

The .cppm extension (and some related extensions) are implicitly recognized as
C++ module interface files. If --precompile is /not/ specified, the file is
compiled (via a .pcm) to a .o file containing the code for the module (and then
potentially also assembled and linked, if -S, -c, etc. are not specified). We
do not yet suppress the emission of object code for other users of the module
interface, so for now this will only work if everything in the .cppm file has
vague linkage.

As with the existing support for module-map modules, prebuilt modules can be
provided as compiler inputs either via the -fmodule-file= command-line argument
or via files named ModuleName.pcm in one of the directories specified via
-fprebuilt-module-path=.

This also exposes the -fmodules-ts cc1 flag in the driver. This is still
experimental, and in particular, the concrete syntax is subject to change as
the Modules TS evolves in the C++ committee. Unlike -fmodules, this flag does
not enable support for implicitly loading module maps nor building modules via
the module cache, but those features can be turned on separately and used in
conjunction with the Modules TS support.

llvm-svn: 280035

[PowerPC] Add triple to test/CodeGen/PowerPC/atomic-2.ll for ppc64le

Otherwise, running the test on Darwin systems will not work.

llvm-svn: 280034

Rename unittests/ADT/ilistTestTemp.cpp => IListTest.cpp

And rename the tests inside from ilistTest to IListTest.  This makes the
file sort properly in the CMakeLists.txt (previously, sorting would
throw it down to the end of the list) and is consistent with the tests
I've added more recently.

Why use IListNodeBaseTest.cpp (and a test name of IListNodeBaseTest)?
- ilist_node_base_test is the obvious thing, since this is testing
  ilist_node_base.  However, gtest disallows underscores in test names.
- ilist_node_baseTest fails for the same reason.
- ilistNodeBaseTest is weird, because it isn't in our usual
  TitleCaseTest form that we use for tests, and it also doesn't have the
  name of the tested class in it.
- IlistNodeBaseTest matches TitleCaseTest, but "Ilist" is hard to read,
  and really "ilist" is an abbreviation for "IntrusiveList" so the
  lowercase "list" is strange.
- That left IListNodeBaseTest.

Note: I made this move in two stages, with a temporary filename of
ilistTestTemp in between in r279524.  This was in the hopes of avoiding
problems on Git and SVN clients on case-insensitive filesystems,
particularly on buildbots with incremental checkouts.

llvm-svn: 280033

ADT: Give ilist<T>::reverse_iterator a handle to the current node

Reverse iterators to doubly-linked lists can be simpler (and cheaper)
than std::reverse_iterator.  Make it so.

In particular, change ilist<T>::reverse_iterator so that it is *never*
invalidated unless the node it references is deleted.  This matches the
guarantees of ilist<T>::iterator.

(Note: MachineBasicBlock::iterator is *not* an ilist iterator, but a
MachineInstrBundleIterator<MachineInstr>.  This commit does not change
MachineBasicBlock::reverse_iterator, but it does update
MachineBasicBlock::reverse_instr_iterator.  See note at end of commit
message for details on bundle iterators.)

Given the list (with the Sentinel showing twice for simplicity):

     [Sentinel] <-> A <-> B <-> [Sentinel]

the following is now true:
 1. begin() represents A.
 2. begin() holds the pointer for A.
 3. end() represents [Sentinel].
 4. end() holds the poitner for [Sentinel].
 5. rbegin() represents B.
 6. rbegin() holds the pointer for B.
 7. rend() represents [Sentinel].
 8. rend() holds the pointer for [Sentinel].

The changes are #6 and #8.  Here are some properties from the old
scheme (which used std::reverse_iterator):
- rbegin() held the pointer for [Sentinel] and rend() held the pointer
  for A;
- operator*() cost two dereferences instead of one;
- converting from a valid iterator to its valid reverse_iterator
  involved a confusing increment; and
- "RI++->erase()" left RI invalid.  The unintuitive replacement was
  "RI->erase(), RE = end()".

With vector-like data structures these properties are hard to avoid
(since past-the-beginning is not a valid pointer), and don't impose a
real cost (since there's still only one dereference, and all iterators
are invalidated on erase).  But with lists, this was a poor design.

Specifically, the following code (which obviously works with normal
iterators) now works with ilist::reverse_iterator as well:

    for (auto RI = L.rbegin(), RE = L.rend(); RI != RE;)
      fooThatMightRemoveArgFromList(*RI++);

Converting between iterator and reverse_iterator for the same node uses
the getReverse() function.

    reverse_iterator iterator::getReverse();
    iterator reverse_iterator::getReverse();

Why doesn't iterator <=> reverse_iterator conversion use constructors?

In order to catch and update old code, reverse_iterator does not even
have an explicit conversion from iterator.  It wouldn't be safe because
there would be no reasonable way to catch all the bugs from the changed
semantic (see the changes at call sites that are part of this patch).

Old code used this API:

    std::reverse_iterator::reverse_iterator(iterator);
    iterator std::reverse_iterator::base();

Here's how to update from old code to new (that incorporates the
semantic change), assuming I is an ilist<>::iterator and RI is an
ilist<>::reverse_iterator:

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

=======================================
Note: bundle iterators are out of scope
=======================================

MachineBasicBlock::iterator, also known as
MachineInstrBundleIterator<MachineInstr>, is a wrapper to represent
MachineInstr bundles.  The idea is that each operator++ takes you to the
beginning of the next bundle.  Implementing a sane reverse iterator for
this is harder than ilist.  Here are the options:
- Use std::reverse_iterator<MBB::i>.  Store a handle to the beginning of
  the next bundle.  A call to operator*() runs a loop (usually
  operator--() will be called 1 time, for unbundled instructions).
  Increment/decrement just works.  This is the status quo.
- Store a handle to the final node in the bundle.  A call to operator*()
  still runs a loop, but it iterates one time fewer (usually
  operator--() will be called 0 times, for unbundled instructions).
  Increment/decrement just works.
- Make the ilist_sentinel<MachineInstr> *always* store that it's the
  sentinel (instead of just in asserts mode).  Then the bundle iterator
  can sniff the sentinel bit in operator++().

I initially tried implementing the end() option as part of this commit,
but updating iterator/reverse_iterator conversion call sites was
error-prone.  I have a WIP series of patches that implements the final
option.

llvm-svn: 280032

[cfi] Export __cfi_check when linking with -fsanitize-cfi-cross-dso.

Multi-DSO CFI model requires every DSO to export a __cfi_check function.

llvm-svn: 280031

AMDGPU/R600: Cleanup DAGCombine

Move SDLoc initialization to comon place.
fall back to AMDGPU version in one place

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

llvm-svn: 280030

Fix typo in test.

llvm-svn: 280028

[ORC] Fix unit-test breakage from r280016.

Void functions returning error now boolean convert to 'false' if they succeed.
Unit tests updated to reflect this.

llvm-svn: 280027

[asan] Attempt to fix test on darwin bot

llvm-svn: 280026

Fix typo in comment. NFC.

llvm-svn: 280025

[ThinLTO] Indirect call promotion fixes for promoted local functions

Summary:
Fix a couple issues limiting the application of indirect call promotion
in ThinLTO mode:
- Invoke indirect call promotion before globalopt, since it may
  eliminate imported functions which appear unreferenced.
- Invoke indirect call promotion with InLTO=true so that the PGOFuncName
  metadata is used to get the name for locals which would have been
  renamed during promotion.

Reviewers: davidxl, mehdi_amini

Subscribers: Prazek, llvm-commits, mehdi_amini

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

llvm-svn: 280024

[CMake] Trying to fix the bots I broke

See: http://lab.llvm.org:8011/builders/libcxx-libcxxabi-x86_64-linux-ubuntu-cxx1z/builds/981/steps/build.libcxxabi/logs/stdio
llvm-svn: 280023

[PowerPC] Fix i8/i16 atomics for little-Endian targets without partword atomics

For little-Endian PowerPC, we generally target only P8 and later by default.
However, generic (older) 64-bit configurations are still an option, and in that
case, partword atomics are not available (e.g. stbcx.). To lower i8/i16 atomics
without true i8/i16 atomic operations, we emulate using i32 atomics in
combination with a bunch of shifting and masking, etc. The amount by which to
shift in little-Endian mode is different from the amount in big-Endian mode (it
is inverted -- meaning we can leave off the xor when computing the amount).

Fixes PR22923.

llvm-svn: 280022

[CMake] Use -std=c++11 if supported

Summary: This patch adds a check for if -std=c++11 is a supported flag, and adds it to CMAKE_CXX_FLAGS if it is supported.

Reviewers: EricWF

Subscribers: cfe-commits

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

llvm-svn: 280021

[SLP] Return a boolean value for these static helpers. NFC.

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

llvm-svn: 280020

AMDGPU/R600: Remove MergeVectorStores from legalization

This is handled by DAGCombiner in a more generic way

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

llvm-svn: 280019

Make lld actually compatible with gold in terms of filler handling.

GNU gold handles output section fillers as 32-bit values.
This patch makes LLD compatible with that behavior.

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

llvm-svn: 280018

[ORC][RPC] Fix typo in RPC comments: call primitives on void functions return
future<Error>, not future<bool>.

llvm-svn: 280017

[ORC][RPC] Make the future type of an Orc RPC call Error/Expected rather than
Optional.

For void functions the return type of a nonblocking call changes from
Expected<future<Optional<bool>>> to Expected<future<Error>>, and for functions
returning T the return type changes from Expected<future<Optional<T>>> to
Expected<future<Expected<T>>>.

Inner results need to be checked (since the RPC connection may have dropped
out before a result came back) and Error/Expected provide stronger checking
requirements. It also allows us drop the crufty 'optionalToError' function and
just collapse Errors in the single-threaded call primitives.

llvm-svn: 280016

libc++: perform configuration checks with -nodefaultlibs

We're compiling libc++ with -nodefaultlibs, so we should also pass this
option during the configuration checks to ensure those checks are
consistent with the actual build.

The primary motivation here is to ease cross-compilation against a
non-standard set of C++ libraries. Previously, the configuration checks
would attempt to link against the standard C++ libraries, which would
cause link failures when cross-compiling, even though the actual library
link would go through correctly (because of the use of -nodefaultlibs
and explicitly specifying any needed libraries). This is more correct
even ignoring the motivation, however.

Patch by Shoaib Meenai!

llvm-svn: 280015

COFF: disambiguate make_unique (NFC)

This disambiguates `llvm::make_unqiue` and `std::make_unique` for the Windows
buildbots.

llvm-svn: 280014

[CMake] Make LLVMConfig.cmake variable names match in-tree names

With the runtimes build we're trying to use LLVMConfig.cmake as a way of providing LLVM_* variables that are needed to behave as if the project is building in tree. To make this work we need to rename two variables by dropping the "S" from the end. This makes the variables match the in-tree names.

This renames:
LLVM_INCLUDE_DIRS -> LLVM_INCLUDE_DIR
LLVM_LIBRARY_DIRS -> LLVM_LIBRARY_DIR

The versions ending in S are not used in-tree anywhere. This also cleans up LLVM_LIBRARY_DIR being set to the same value with and without the "S".

llvm-svn: 280013

COFF: add beginnings of debug directory creation

The IMAGE_FILE_HEADER structure contains a (RVA, size) to an array of
COFF_DEBUG_DIRECTORY records. Each one of these records contains an RVA to a OMF
Debug Directory. These OMF debug directories are derived into newer types such
as PDB70, PDB20, etc. This constructs a PDB70 structure which will allow us to
associate a GUID with a build to actually tie debug information.

llvm-svn: 280012

GlobalISel: use multi-dimensional arrays for legalize actions.

Instead of putting all possible requests into a single table, we can perform
the extremely dense lookup based on opcode and type-index in constant time
using multi-dimensional array-like things.

This roughly halves the time spent doing legalization, which was dominated by
queries against the Actions table.

llvm-svn: 280011

Fix a bug preventing the cause for a module file-not-found from being displayed

llvm-svn: 280010

Fix a bug preventing the cause of a module-out-of-date error from being printed

llvm-svn: 280009

Fix a thinko in r278189.

llvm-svn: 280008

Fix or suppress GCC warnings during build.

Summary:
Currently a number of GCC warnings are emitted when building libc++. This patch fixes or ignores all of them. The primary changes are:

* Work around strict aliasing issues in `typeinfo::hash_code()` by using __attribute__((may_alias)). However I think a non-aliasing `hash_code()` implementation is possible. Further investigation needed.
* Add `_LIBCPP_UNREACHABLE()` to switch in `strstream.cpp` to avoid -Wpotentially-uninitialized.
* Fix -Wunused-value warning in `__all` by adding a void cast.
* Ignore -Wattributes for now. There are a number of real attribute issues when using GCC but enabling the warning is too noisy.
* Ignore -Wliteral-suffix since it warns about the use of reserved identifiers. Note Only GCC 7.0 supports disabling this warning.
* Ignore -Wc++14-compat since it warns about the sized new/delete overloads.

Reviewers: EricWF

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

llvm-svn: 280007

AMDGPU: fix mismatch tags, NFC

llvm-svn: 280006

ExecutionEngine: fix a bug in the movt/movw relocator

According to the arm arm specifications, 4 bytes are needed for a shift instead
of 8, this was causing the movt instruction to write to a different register
sometimes.

Patch by Walter Erquinigo!

llvm-svn: 280005

[CMake] Builtins build needs LLVM_*_OUTPUT_INTDIR variables

This allows the builtins archives to build into the correct subdirectory under the binary dir. Addresses the issue discussed in D24001.

llvm-svn: 280002

[LV] Move insertelement sequence after scalar definitions

After r279649 when getting a vector value from VectorLoopValueMap, we create an
insertelement sequence on-demand if the value has been scalarized instead of
vectorized. We previously inserted this insertelement sequence before the
value's first vector user. However, this insert location is problematic if that
user is the phi node of a first-order recurrence. With this patch, we move the
insertelement sequence after the last scalar instruction we created when
scalarizing the value. Thus, the value's vector definition in the new loop will
immediately follow its scalar definitions. This should fix PR30183.

Reference: https://llvm.org/bugs/show_bug.cgi?id=30183
llvm-svn: 280001

Convert GetNameColonValue to return StringRefs.

StringExtractor::GetNameColonValue() looks for a substring of the
form "<name>:<value>" and returns <name> and <value> to the caller.
This results in two unnecessary string copies, since the name and
value are not translated in any way and simply returned as-is.

By converting this to return StringRefs we can get rid of hundreds
of string copies.

llvm-svn: 280000

Turn On -DLIBCXX_ENABLE_BENCHMARKS by default.

This patch enables the `cxx-benchmarks` target by default. Note that the target
still has to be manually invoked since it isn't included in the default 'make'
rule.

This patch also gets the benchmarks building w/ GCC. The build previously
required the '-stdlib=libc++' flag but upstream patches to Google Benchmark
now allow the library to build w/ libc++ and GCC.

These changes should make the benchmarks easier to build and test.

llvm-svn: 279999

Propagate TBAA info in SelectionDAG::getIndexedLoad

Patch by Pranav Bhandarkar.

llvm-svn: 279998

Copy StringExtractor to StdStringExtractor.

I have some improvements to make to StringExtractor that require
using LLVM.  debugserver can't take a dependency on LLVM but uses
this file, so I'm forking it off into StdStringExtractor and
StringExtractor, so that StringExtractor can take advantage of
some performance improvements and readability improvements that
LLVM can provide.

llvm-svn: 279997

[Myriad]: add missing 'mcpu' values

Should have been done with r276646.

llvm-svn: 279996

AMDGPU/SI: Implement a custom MachineSchedStrategy

Summary:
GCNSchedStrategy re-uses most of GenericScheduler, it's just uses
a different method to compute the excess and critical register
pressure limits.

It's not enabled by default, to enable it you need to pass -misched=gcn
to llc.

Shader DB stats:

32464 shaders in 17874 tests
Totals:
SGPRS: 1542846 -> 1643125 (6.50 %)
VGPRS: 1005595 -> 904653 (-10.04 %)
Spilled SGPRs: 29929 -> 27745 (-7.30 %)
Spilled VGPRs: 334 -> 352 (5.39 %)
Scratch VGPRs: 1612 -> 1624 (0.74 %) dwords per thread
Code Size: 36688188 -> 37034900 (0.95 %) bytes
LDS: 1913 -> 1913 (0.00 %) blocks
Max Waves: 254101 -> 265125 (4.34 %)
Wait states: 0 -> 0 (0.00 %)

Totals from affected shaders:
SGPRS: 1338220 -> 1438499 (7.49 %)
VGPRS: 886221 -> 785279 (-11.39 %)
Spilled SGPRs: 29869 -> 27685 (-7.31 %)
Spilled VGPRs: 334 -> 352 (5.39 %)
Scratch VGPRs: 1612 -> 1624 (0.74 %) dwords per thread
Code Size: 34315716 -> 34662428 (1.01 %) bytes
LDS: 1551 -> 1551 (0.00 %) blocks
Max Waves: 188127 -> 199151 (5.86 %)
Wait states: 0 -> 0 (0.00 %)

Reviewers: arsenm, mareko, nhaehnle, MatzeB, atrick

Subscribers: arsenm, kzhuravl, llvm-commits

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

llvm-svn: 279995

Remove std::atomic from lldb::Address.

std::atomic<uint64_t> requires 64-bit alignment in order to
guarantee atomicity.  Normally the compiler is pretty good about
aligning types, but an exception to this is when the type is
passed by value as a function parameter.  In this case, if your
stack is 4-byte aligned, most modern compilers (including clang
as of LLVM 4.0) fail to align the type, rendering the atomicity
ineffective.

A deeper investigation of the class's implementation suggests
that the use of atomic was in vain anyway, because if the class
were to be shared amongst multiple threads, there were already
other data races present, and that the proper way to ensure
thread-safe access to this data would be to use a mutex from a
higher level.

Since the std::atomic was not serving its intended purpose anyway,
and since the presence of it generates compiler errors on some
platforms that cannot be workaround, we remove std::atomic from
Address here.  Although unlikely, if data races do resurface
the proper fix should involve a mutex from a higher level, or an
attempt to limit the Address's access to a single thread.

llvm-svn: 279994

[asan] Enable new stack poisoning with store instruction by default

Reviewers: eugenis

Subscribers: llvm-commits

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

llvm-svn: 279993

GlobalISel: switch to SmallVector for pending legalizations.

std::queue was doing far to many heap allocations to be healthy.

llvm-svn: 279992

AMDGPU/SI: Improve SILoadStoreOptimizer and run it before the scheduler

Summary:
The SILoadStoreOptimizer can now look ahead more then one instruction when
looking for instructions to merge, which greatly improves the number of
loads/stores that we are able to merge.

Moving the pass before scheduling avoids increasing register pressure after
the scheduler, so that the scheduler's register pressure estimates will be
more accurate.  It also gives more consistent results, since it is no longer
affected by minor scheduling changes.

Reviewers: arsenm

Subscribers: arsenm, kzhuravl, llvm-commits

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

llvm-svn: 279991

ASan: remove variable only used in assertions build

llvm-svn: 279990

Update Google Benchmark library.

llvm-svn: 279989

GlobalISel: legalize frem to a libcall on AArch64.

llvm-svn: 279988

GlobalISel: rework CallLowering so that it can be used for libcalls too.

There should be no functional change here, I'm just making the implementation
of "frem" (to libcall) legalization easier for a followup.

llvm-svn: 279987

AMDGPU/R600: Fix fixups used for constant arrays

Fixes bug 29289

llvm-svn: 279986

IfConversion: Fix branch predication bug.

This bug shows up with diamonds that share unpredicable, unanalyzable branches.
There's an included test case from Hexagon. What was happening was that we were
attempting to predicate the branch instruction despite the fact that it was
checked to be the same. Now for unanalyzable branches we skip over the branch
instructions when predicating the block.

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

llvm-svn: 279985

Use store operation to poison allocas for lifetime analysis.

Summary:
Calling __asan_poison_stack_memory and __asan_unpoison_stack_memory for small
variables is too expensive.

Code is disabled by default and can be enabled by -asan-experimental-poisoning.

PR27453

Reviewers: eugenis

Subscribers: llvm-commits

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

llvm-svn: 279984

[scudo] use 32 bits of ASLR entropy instead of just 24 when shuffling allocated chunks

llvm-svn: 279983

[asan] Separate calculation of ShadowBytes from calculating ASanStackFrameLayout

Summary: No functional changes, just refactoring to make D23947 simpler.

Reviewers: eugenis

Subscribers: llvm-commits

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

llvm-svn: 279982

[asan] Remove runtime flag detect_stack_use_after_scope

Summary:
We are going to use store instructions to poison some allocas.
Runtime flag will require branching in instrumented code on every lifetime
intrinsic. We'd like to avoid that.

Reviewers: eugenis

Subscribers: llvm-commits, kubabrecka

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

llvm-svn: 279981

[SimplifyCFG] Hoisting invalidates metadata

We forgot to remove optimization metadata when performing hosting during
FoldTwoEntryPHINode.

This fixes PR29163.

llvm-svn: 279980

Make vec_fabs.ll pass with MSVC 2013

We should revert this change once we drop support for MSVC 2013.

llvm-svn: 279979

Try to fix clang-offload-bunder.c test once more

llvm-svn: 279978

[gold] Fix test accidentally regressed for newer gold

With r279911 I accidentally regressed the gold/X86/start-lib-common.ll
test for newer golds (v1.12+) that honor the --start-lib/--end-lib.
Remove the alignment which should not be there to make this work with
both old and new gold linkers.

Additionally, now that we have a subdirectory for v1.12+ gold tests,
copy this test there and check specifically for the v1.12+ behavior.

llvm-svn: 279977

[AArch64] Adjust the scheduling model for Exynos M1.

Further refine the model for loads.

llvm-svn: 279976

[StatepointsForGC] Rematerialize in the presence of PHIs

Summary:
While walking the use chain for identifying rematerializable values in RS4GC,
add the case where the current value and base value are the same PHI nodes.

This will aid rematerialization of geps and casts instead of relocating.

Reviewers: sanjoy, reames, igor

Subscribers: llvm-commits

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

llvm-svn: 279975