llvm-svn: 275762

While debugging GVNHoist, I found it confusing that the entries in a
VNtoInsns were not always value numbers.  They _usually_ were except for
StoreInst in which case they were a hash of two different value numbers.

This leads to two observations:
- It is more difficult to debug things when the semantic contents of
  VNtoInsns changes over time.
- Using a single value number is not much cheaper, the value of
  VNtoInsns is a SmallVector.
- It is not immediately clear what the algorithm would do if there were
  hash collisions in the StoreInst case.

Using a DenseMap of std::pair sidesteps all of this.

N.B.  The changes in the test were due their sensitivity to the
iteration order of VNtoInsns which has changed.

llvm-svn: 275761

man page for mkdir says: "If the parent directory has the set-group-ID bit set,
then so will the newly created directory."

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

llvm-svn: 275760

This patch updates the way libc++ handles checking for libatomic, in part
to prepare for https://reviews.llvm.org/D22073.

Changes:
* 'LIBCXX_HAS_ATOMIC_LIB' is now set whenever libatomic is available even libc++
   doesn't need to manually link it.
* 'LIBCXX_HAVE_CXX_ATOMICS_WITH_LIB' is now used to detect when libatomic
   needs to be manually linked.
* 'LIBCXX_HAS_ATOMIC_LIB' now adds 'libatomic' as a available feature in the
   test suite.

llvm-svn: 275759

Don't make the test/tools/llvm-cov/demangle.test depend on the order in
which symbols are seen, or on the exact formatting llvm-cov emits after
a symbol is printed. This is an attempt to fix a Windows bot failure:

  http://lab.llvm.org:8011/builders/clang-x86-win2008-selfhost/builds/9141

I don't know what the root cause of the failure is, or why the
showTemplateInstantiations test doesn't fail in the same way on the
Windows bots. However, this measure can't hurt, and it'll at least get
me on the blamelists again.

llvm-svn: 275758

llvm-svn: 275757

This reverts also r275029, "Update Clang tests after adding inference for the returned argument attribute"

It broke LTO build. Seems miscompilation.

llvm-svn: 275756

llvm-svn: 275754

llvm-svn: 275753

llvm-svn: 275752

llvm-svn: 275751

llvm-svn: 275750

This patch does the following:

* It renames `_LIBCPP_TRIVIAL_PAIR_COPY_CTOR` to `_LIBCPP_DEPRECATED_ABI_DISABLE_PAIR_TRIVIAL_COPY_CTOR`.
* It automatically enables this option on FreeBSD in ABI V1, since that's the current ABI FreeBSD ships.
* It cleans up the handling of this option in `std::pair`.

I would like the sign off from the FreeBSD maintainers. They will no longer need to keep their `__config` changes downstream.

I'm still hoping to come up with a better way to maintain the ABI without needing these constructors.

Reviewed in https://reviews.llvm.org/D21329

llvm-svn: 275749

llvm-svn: 275748

In the last patch for --trace-symbol, I introduced a new symbol type
PlaceholderKind and store it to SymVector storage. It made all code
that iterates over SymVector to recognize and skip PlaceholderKind
symbols. I found that that's annoying.

In this patch, I removed PlaceholderKind and stop storing them to SymVector.
Now the information whether a symbol is being watched by --trace-symbol
is stored to the Symtab hash table.

llvm-svn: 275747

SymVector contains all symbols, so we can iterate either Symtab or SymVector
to visit all symbols. Iterating over SymVector makes the next change for
--trace-symbol possible.

llvm-svn: 275746

This patch upgrades <tuple> to be C++17 compliant by implementing:

* tuple_size_v: This was forgotten when implementing the other _v traits.
* std::apply: This was added via LFTS v1 in p0220r1.
* std::make_from_tuple: This was added in p0209r2.

llvm-svn: 275745

HoistedCtr cannot be a mutated global variable, that will open us up to
races between threads compiling code in parallel.

llvm-svn: 275744

No functional change is intended, just trying to clean things up a
little.

llvm-svn: 275743

llvm-svn: 275742

llvm-svn: 275741

Summary:
Aiming to resolve failure in sanitizer bot by changning all asm directives to __asm__.
Also, consistency.

Reviewers: llvm-commits, echristo, vitalybuka

Subscribers: mehdi_amini

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

llvm-svn: 275740

llvm-svn: 275739

The test was relying on the default triple which may not be correct.  Explicitly
provide it a triple.  Should repair the windows on Linux builder.

llvm-svn: 275738

Add support for ObjC types to respect the DLLImport/DLLExport storage
annotations.  This only effects COFF output.  This would allow usage with
clang/C2, but not with clang/LLVM due to hard coded section names.

llvm-svn: 275737

Format some code which was oddly formatted.  Use a bit of auto to make the code
more legible.  NFC.

llvm-svn: 275736

Clean up some formatting issues and use a bit more StringRef based operations
instead of SmallStrings.  NFC.

llvm-svn: 275735

This patch implements a simple optimization in __hash_table::find. When iterating
the found bucket we only constrain the bucket elements hash if it doesn't
already match the unconstrained hash of the specified key. This prevent
the performance of an expensive modulo operation.

Since the bucket element almost always matches the key, especially when the
load factor is low, this optimization has large performance impacts. For
a unordered_set<int> of random integers this patch improves the performance of
'find(...)' by 40%.

llvm-svn: 275734

a base class and a derived class, with the derived class containing
the methods specific to reading dyld's all_image_infos, dyld's
method of specifying images that have been loaded or unloaded, the
place where we put a breakpoint in dyld to get notified about newly
loaded or unloaded images.

This is in preparation for a second derived class which will use
some alternate methods for getting this information; that will be
a separate commit in the next few days.

There's a couple of ivars that should probably be in the derived
DyanmicLoaderMacOSX class instead of the base DynamicLoaderDarwin
class (m_dyld_image_infos, m_dyld_image_infos_stop_id).  I don't
think I'll need to use these in the new derived class - I'll 
move them down to DynamicLoaderMacOSX if it works out that way;
it'll simplify locking if I can do that.

<rdar://problem/25251243> 

llvm-svn: 275733

llvm-svn: 275732

case Process::GetFileLoadAddress fails to set it to a real
value.  (fixing "conditional use of garbage value" clang warning)

llvm-svn: 275731

llvm-svn: 275730

llvm-svn: 275729

llvm-svn: 275728

llvm-svn: 275727

llvm-svn: 275726

llvm-svn: 275725

llvm-svn: 275724

Summary:
Given that we had a bug on max/minUIntN(64), these should have tests
too.

Reviewers: rnk

Subscribers: dylanmckay, llvm-commits

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

llvm-svn: 275723

Summary:
Previously we were relying on 2's complement underflow in an int64_t.
Now we cast to a uint64_t so we explicitly get the behavior we want.

Reviewers: rnk

Subscribers: dylanmckay, llvm-commits

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

llvm-svn: 275722