llvm-svn: 328285

With this patch lld will iterate over compile units to find the line
tables instead of assuming there is only one at offset 0.

llvm-svn: 328284

llvm-svn: 328283

Changes the analyzer to believe that methods annotated with _Nonnull
from system frameworks indeed return non null objects.
Local methods with such annotation are still distrusted.
rdar://24291919

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

llvm-svn: 328282

rdar://38480416

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

llvm-svn: 328281

Current location is very confusing, especially because there is already
WorkList.h, and other code in CoreEngine.cpp is not related to work list
implementation.

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

llvm-svn: 328280

llvm-svn: 328279

llvm-svn: 328278

Putting back the code in commit r327189 that was reverted in r322737. The code is being committed in three stages and this one is the last stage: 1) r327455 fp16 feature flags, 2) r327836 pass half type or i16 based on FullFP16, and 3) the code here which the front-end fp16 vector intrinsic for ARM.

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

llvm-svn: 328277

...and add some very basic stack trace entries for module building.
This would have helped track down rdar://problem/38434694 sooner.

llvm-svn: 328276

The full vector is being returned not a reference. So the reference was just a to a temporary.

llvm-svn: 328275

cases when printing symbols.  As an improvement to:

r305733 - Change llvm-nm for Mach-O files to use dyld info in some cases when printing symbols

it could be made a bit better if it also read the function starts and faked
up nlist entries to those address not already faked up by the other
dyld info.  This would help with stripped static functions.

rdar://38761029

llvm-svn: 328274

The system call now fails when it cannot write the requested size.
Update the sanitizer runtime Fuchsia implementation accordingly.

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

llvm-svn: 328273

That removes some redundant recomputations from the passes pipeline.

llvm-svn: 328272

Summary: unique_lock has the overhead of tracking ownership status and the owner.

Reviewers: grimar, zturner

Subscribers: llvm-commits

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

llvm-svn: 328271

Fixed windows release build tests.

llvm-svn: 328270

Some debian libc++ bots started having failures in the locale
tests due to what I assume is a change in the locale data for fr_FR
in glibc.

This change prints the actual value from the test to help debugging.
It should be reverted once the bots cycle.

llvm-svn: 328268

llvm-svn: 328267

llvm-svn: 328266

This fixes a couple of tests which produced a warning that a 'throw'
occurred in a noexcept function (by way of _LIBCPP_ASSERT). It does
so by hiding the 'throw' across an opaque function boundary.

This fix isn't ideal, since we still have _LIBCPP_ASSERT's in functions
marked noexcept -- and this problem should be addressed in the future.
However, throwing _LIBCPP_ASSERT is really only meant to allow testing
of the assertions, and is not yet ready for general use.

llvm-svn: 328265

llvm-svn: 328264

This would have found the regression in r328238.

llvm-svn: 328263

llvm-svn: 328262

This patch works around variant test failures which are new to
GCC 8. GCC 8 either doesn't perform SFINAE in lexical order, or
it doesn't halt after encountering the first failure. This
causes hard error to occur instead of substitution failure.

See gcc.gnu.org/PR78489

llvm-svn: 328261

llvm-svn: 328260

llvm-svn: 328259

When a temporary is constructed with a proper construction context, it should
be safe to inline the destructor. We have added suppressions for some of the
common false positives caused by such inlining, so there should be - and from my
observations there indeed is - more benefit than harm from enabling destructor
inlining.

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

llvm-svn: 328258

Summary:
Revert r325687 workaround for PR36032 since
 a fix was committed in r326154.

Reviewers: sbaranga

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

From: Evgeny Stupachenko <evstupac@gmail.com>
                         <evgeny.v.stupachenko@intel.com>
llvm-svn: 328257

Patch by Christopher James Halse Rogers!

llvm-svn: 328256

CXXCtorInitializer-based constructors are also affected by the C++17 mandatory
copy elision, like variable constructors and return value constructors.
Extend r328248 to support those.

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

llvm-svn: 328255

[X86] Rename VROUNDYPS* and VROUNDYPD* instructions to VROUNDPSY* and VROUNDPDY*. Fix itinerary mistake on all memory forms of VROUNDPD

This makes the Y position consistent with other instructions.

This should have been NFC, but while refactoring the multiclass I noticed that VROUNDPD memory forms were using the register itinerary.

llvm-svn: 328254

Function return values can be constructed directly in variables or passed
directly into return statements, without even an elidable copy in between.
This is how the C++17 mandatory copy elision AST behaves. The behavior we'll
have in such cases is the "old" behavior that we've had before we've
implemented destructor inlining and proper lifetime extension support.

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

llvm-svn: 328253

In our real world application, we found the following optimization is missed in DAGCombiner

(zext (and/or/xor (shl/shr (load x), cst), cst)) -> (and/or/xor (shl/shr (zextload x), (zext cst)), (zext cst))

If the user of original zext is an add, it may enable further lea optimization on x86.

This patch add a new function CombineZExtLogicopShiftLoad to do this optimization.

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

llvm-svn: 328252

Transforms/Scalar/SCCP.cpp implemented both the Scalar and IPO SCCP, but
this meant Transforms/Scalar including Transfroms/IPO headers, creating
a circular dependency. (IPO depends on Scalar already) - so move the IPO
SCCP shims out into IPO and the basic library implementation accessible
from Scalar/SCCP.h to be used from the IPO/SCCP.cpp implementation.

llvm-svn: 328250

Improve readability of ConstructionContext::createFromLayers().

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

llvm-svn: 328249

In C++17 copy elision is mandatory for variable and return value constructors
(as long as it doesn't involve type conversion) which results in AST that does
not contain elidable constructors in their usual places. In order to provide
construction contexts in this scenario we need to cover more AST patterns.

This patch makes the CFG prepared for these scenarios by:

- Fork VariableConstructionContext and ReturnedValueConstructionContext into
  two different sub-classes (each) one of which indicates the C++17 case and
  contains a reference to an extra CXXBindTemporaryExpr.
- Allow CFGCXXRecordTypedCall element to accept VariableConstructionContext and
  ReturnedValueConstructionContext as its context.

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

llvm-svn: 328248

If a memory region (or an SVal that represents a pointer to that memory region)
is a (direct or indirect, not necessarily proper) sub-region of a SymbolicRegion
then it is said to have a symbolic base.

For now SVal::symbol_iterator explores the symbol within a symbolic region
only when the SVal represents a pointer to the symbolic region itself,
not to any of its sub-regions.

This behavior is not indended by any user of symbol_iterator; all users who
cared about such behavior were expecting the iterator to descend into the
symbolic base of an arbitrary region, find the parent symbol of the symbolic
base region, and iterate over that symbol. Lack of such behavior resulted in
bugs demonstarted by the test cases.

Hence the decision to change the API to behave more intuitively.

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

llvm-svn: 328247

Value::printAsOperand has been scanning the entire module just to
print a single value as an operand, regardless being asked to print a
type or not at all, and regardless really needing to scan the module
to print a type.

It made some of the users of the method exceptionally slow on large
IR-modules (or large MIR-files with large IR-modules embedded).

This patch defers scanning a module looking for struct types, mostly
numbered struct types, as much as possible, speeding up those users
w/o changing any APIs at all.

See speedup examples below:

Release Build:

# 83 seconds -> 5.5 seconds
time ./bin/llc -start-before=irtranslator -stop-after=irtranslator \
  -global-isel -global-isel-abort=2 -simplify-mir sqlite3.O0.ll -o \
  sqlite3.O0.ll.regbankselected.mir

# 133 seconds -> 6.2 seconds
time ./bin/opt sqlite3.O0.ll -dot-cfg -disable-output

Release + Asserts Build:

# 95 seconds -> 5.5 seconds
time ./bin/llc -start-before=irtranslator -stop-after=irtranslator \
  -global-isel -global-isel-abort=2 -simplify-mir sqlite3.O0.ll -o \
  sqlite3.O0.ll.regbankselected.mir

# 146 seconds -> 6.2 seconds
time ./bin/opt sqlite3.O0.ll -dot-cfg -disable-output

# 1096 seconds -> 553 seconds
time ./bin/llc -debug-only=isel -fast-isel=false -stop-after=isel \
  sqlite3.O0.ll -o /dev/null 2> err

where sqlite3.O0.ll is non-optimized IR produced from
sqlite-amalgamation (http://sqlite.org/download.html), which is entire
SQLite3 implementation in a single C-file.

Benchmarked on 4-cores / 8 threads PCI-E SSD iMac running macOS

Reviewers: dexonsmith, bkramer, void, chandlerc, aditya_nandakumar, dsanders, qcolombet, 

Reviewed By: bogner

Subscribers: thegameg, llvm-commits

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

llvm-svn: 328246

The new/delete tests, in particular those which test replacement
functions, often fail when the optimizer is enabled because the
calls to new/delete may be optimized away, regardless of their side-effects.

This patch converts the tests to use DoNotOptimize in order to prevent
the elision.

llvm-svn: 328245

Summary:
This reverts commit 364eb09576a7667bc6d3ff80c52a83014ccac976 and separates out
the portion that was fixing binary reader error propagation - turns out, there
are production cases where that causes a regression.

Will re-introduce the error propagation fix separately.

The fix to the text reader error propagation is still "in".

Reviewers: bkramer

Reviewed By: bkramer

Subscribers: llvm-commits

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

llvm-svn: 328244