emplace_back is not faster if it is equivalent to push_back. In this cases emplaced value had the
same type that the one stored in container. It is ugly and it might be even slower (see
Scott Meyers presentation about emplacement).

llvm-svn: 290685

Summary:
This index record the position for each metadata record in
the bitcode, so that the reader will be able to lazy-load
on demand each individual record.

We also make sure that every abbrev is emitted upfront so
that the block can be skipped while reading.

I don't plan to commit this before having the reader
counterpart, but I figured this can be reviewed mostly
independently.

Reviewers: pcc, tejohnson

Subscribers: llvm-commits

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

llvm-svn: 290684

llvm-svn: 290683

This was hardcoded to be O3 till now, without any way to change it
without changing the code.

llvm-svn: 290682

Another set of isl coalesce changes.

llvm-svn: 290681

llvm-svn: 290680

llvm-svn: 290679

Jump table emission can switch to .rdata before
WinException::endFunction gets called. Just remember the appropriate
text section we started in and reset back to it when we end the
function. We were already switching sections back from .xdata anyway.

Fixes the first problem in PR31488, so that now COFF switch tables can
live in .rdata if we want them to.

llvm-svn: 290678

llvm-svn: 290677

Accidental commit. LLVM changes have not been pushed yet
This reverts commit 592453413690a2d16784667d1644758b9af700c1.

llvm-svn: 290676

llvm-svn: 290675

Summary:
We can simply import all external values with summaries included in
the individual index file created for the distributed backend job,
as only those are added to the individual index file created by the
WriteIndexesThinBackend (in addition to summaries for the original
module, which are skipped here).

While computing the cross module imports on this index would come to
the same conclusion as the original thin link import logic, it is
unnecessary work. And when tuning, it avoids the need to pass the
same function importing parameters (e.g. -import-instr-limit) to
both the thin link and the backends (otherwise they won't make the
same decisions).

Reviewers: mehdi_amini, pcc

Subscribers: cfe-commits

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

llvm-svn: 290674

llvm-svn: 290673

This reverts commit r290569. It caused unforeseen codegen changes for
switch jump tables described in PR31488.

llvm-svn: 290672

One of the intended checks was not being performed.

llvm-svn: 290671

llvm-svn: 290670

llvm-svn: 290669

llvm-svn: 290668

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

llvm-svn: 290667

llvm-svn: 290666

This is an orthogonal and separated layer instead of being embedded
inside the pass manager. While it adds a small amount of complexity, it
is fairly minimal and the composability and control seems worth the
cost.

The logic for this ends up being nicely isolated and targeted. It should
be easy to experiment with different iteration strategies wrapped around
the CGSCC bottom-up walk using this kind of facility.

The mechanism used to track devirtualization is the simplest one I came
up with. I think it handles most of the cases the existing iteration
machinery handles, but I haven't done a *very* in depth analysis. It
does however match the basic intended semantics, and we can tweak or
tune its exact behavior incrementally as necessary. One thing that we
may want to revisit is freshly building the value handle set on each
iteration. While I don't think this will be a significant cost (it is
strictly fewer value handles but more churn of val...

analyses when we're about to break apart an SCC.

We can't wait until after breaking apart the SCC to invalidate things:
1) Which SCC do we then invalidate? All of them?
2) Even if we invalidate all of them, a newly created SCC may not have
   a proxy that will convey the invalidation to functions!

Previously we only invalidated one of the SCCs and too late. This led to
stale analyses remaining in the cache. And because the caching strategy
actually works, they would get used and chaos would ensue.

Doing invalidation early is somewhat pessimizing though if we *know*
that the SCC structure won't change. So it turns out that the design to
make the mutation API force the caller to know the *kind* of mutation in
advance was indeed 100% correct and we didn't do enough of it. So this
change also splits two cases of switching a call edge to a ref edge into
two separate APIs so that callers can clearly test for this and take the
easy path without invalidating when appropriate. This is particularly
important in this case as we expect most inlines to be between functions
in separate SCCs and so the common case is that we don't have to so
aggressively invalidate analyses.

The LCG API change in turn needed some basic cleanups and better testing
in its unittest. No interesting functionality changed there other than
more coverage of the returned sequence of SCCs.

While this seems like an obvious improvement over the current state, I'd
like to revisit the core concept of invalidating within the CG-update
layer at all. I'm wondering if we would be better served forcing the
callers to handle the invalidation beforehand in the cases that they
can handle it. An interesting example is when we want to teach the
inliner to *update and preserve* analyses. But we can cross that bridge
when we get there.

With this patch, the new pass manager an build all of the LLVM test
suite at -O3 and everything passes. =D I haven't bootstrapped yet and
I'm sure there are still plenty of bugs, but this gives a nice baseline
so I'm going to increasingly focus on fleshing out the missing
functionality, especially the bits that are just turned off right now in
order to let us establish this baseline.

llvm-svn: 290664

This is a large patch for X86 AVX-512 of an optimization for reducing code size by encoding EVEX AVX-512 instructions using the shorter VEX encoding when possible.

There are cases of AVX-512 instructions that have two possible encodings. This is the case with instructions that use vector registers with low indexes of 0 - 15 and do not use the zmm registers or the mask k registers.
The EVEX encoding prefix requires 4 bytes whereas the VEX prefix can take only up to 3 bytes. Consequently, using the VEX encoding for these instructions results in a code size reduction of ~2 bytes even though it is compiled with the AVX-512 features enabled.

Reviewers: Craig Topper, Zvi Rackoover, Elena Demikhovsky 
Differential Revision: https://reviews.llvm.org/D27901

llvm-svn: 290663

In C++03 libc++ emulates nullptr_t using a class, and #define's nullptr.
However this makes nullptr_t mangle differently between C++03 and C++11.
This breaks any function ABI which takes nullptr_t.

Thanfully Clang provides __nullptr in all dialects. This patch adds
an ABI option to switch to using __nullptr in C++03. In a perfect world
I would like to turn this on by default, since it's just ABI breaking fix
to an ABI breaking bug.

llvm-svn: 290662

Our newly aggressive constant folding logic makes it possible for
CGExprConstant to see the same CompoundLiteralExpr more than once. So,
emitting a new GlobalVariable every time we see a CompoundLiteral is no
longer correct.

We had a similar issue with BlockExprs that was caught while testing
said aggressive folding, so I applied the same style of fix (see D26410)
here. If we find yet another case where this needs to happen, we should
probably refactor this so we don't have a third DenseMap+getter+setter.

As a design note: getAddrOfConstantCompoundLiteralIfEmitted is really
only intended to be called by ConstExprEmitter::EmitLValue. So,
returning a GlobalVariable* instead of a ConstantAddress costs us
effectively nothing, and saves us either a few bytes per entry in our
map or a bit of code duplication.

llvm-svn: 290661

parameter. Fixes failed deduction for 'auto' non-type template parameters
nested within templates.

llvm-svn: 290660

llvm-svn: 290659

llvm-svn: 290658

llvm-svn: 290657

llvm-svn: 290656

llvm-svn: 290655

llvm-svn: 290654

llvm-svn: 290653

llvm-svn: 290652

This patch implements changes to allow _LIBCPP_ASSERT to throw on failure
instead of aborting. The main changes needed to do this are:

1. Change _LIBCPP_ASSERT to call a handler via a replacable function pointer
   instead of calling abort directly. Additionally this patch implements two
   handler functions, one which aborts and another that throws an exception.

2. Add _NOEXCEPT_DEBUG macro for disabling noexcept spec on function which
   contain _LIBCPP_ASSERT. This is required in order to prevent assertion
   failures throwing through a noexcept function. This macro has no effect
   unless _LIBCPP_DEBUG_USE_EXCEPTIONS is defined.

Having a non-aborting _LIBCPP_ASSERT is very important to allow sane testing of
debug mode. Currently we can only have one test case per file, since the test
case will cause the program to abort. Testing debug mode this way would require
thousands of test files, most of which would be 95% boiler plate. I don't think
this is a feasible strategy. Fortunately using a throwing debug handler solves
these issues.

Additionally this patch rewrites the documentation for debug mode.

llvm-svn: 290651

Summary:
All easy-to-find bugs in cxa_demangle where fixed now
(https://bugs.chromium.org/p/chromium/issues/detail?id=606626)
except for one (https://llvm.org/bugs/show_bug.cgi?id=31031).
Now I'd like to properly integrate this fuzzer with the source tree
and then run the fuzzer continuously on https://github.com/google/oss-fuzz

Reviewers: compnerd, mclow.lists, mehdi_amini

Subscribers: cfe-commits, mgorny

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

llvm-svn: 290650

when they are call edges at the leaf but may (transitively) be reached
via ref edges.

It turns out there is a simple rule: insert everything as a ref edge
which is a safe conservative default. Then we let the existing update
logic handle promoting some of those to call edges.

Note that it would be fairly cheap to make these call edges right away
if that is desirable by testing whether there is some existing call path
from the source to the target. It just seemed like slightly more
complexity in this code path that isn't strictly necessary. If anyone
feels strongly about handling this differently I'm happy to change it.

llvm-svn: 290649

[InstCombine] Remove a piece of a comment that said that InstCombiner contains pass infrastructure. That hasn't been true since r226618. NFC

llvm-svn: 290648

to make reference to template parameters. This is only a partial
implementation; we retain the restriction that the argument must not be
type-dependent, since it's unclear how that would work given the existence of
other language rules requiring an exact type match in this context, even for
type-dependent cases (a question has been raised on the core reflector).

llvm-svn: 290647

r290644. Sorry for this.

llvm-svn: 290646