We build it as an LLVM tool.

llvm-svn: 289645

Summary: This code was probably needed to support VS2013 and is not needed now. I have built it with VS and mingw. Ok to remove it?

Reviewers: zturner, abidh

Subscribers: lldb-commits

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

llvm-svn: 289644

Currently, the error messages we emit for the .org directive when the
expression is not absolute or is out of range do not include the line
number of the directive, so it can be hard to track down the problem if
a file contains many .org directives.

This patch stores the source location in the MCOrgFragment, so that it
can be used for diagnostics emitted during layout.

Since layout is an iterative process, and the errors are detected during
each iteration, it would have been possible for errors to be reported
multiple times. To prevent this, I've made the assembler bail out after
each iteration if any errors have been reported. This will still allow
multiple unrelated errors to be reported in the common case where they
are all detected in the first round of layout.

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

llvm-svn: 289643

    
The eglibc library, as used by Ubuntu 14.04 requires the presence of an
SHT_ARM_ATTRIBUTES section in for the purposes of checking hard/soft float
compatibility when dlopen() is used. Unfortunately when the section is not
present dlopen() fails with a generic could not find file message.
    
This change makes lld keep the first .ARM.attributes section that it
encounters and propagates it to the output. This is not a complete
SHT_ARM_ATTRIBUTES implementation, that would involve reading the contents
of the section and joining each individual attribute. It should suffice
for a homogenous build all libraries and executables on the same system
with a compatible set of command line options.

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

llvm-svn: 289642

This will be used for an on-chip test suite.

llvm-svn: 289641

Patch by Victor Campos.

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

llvm-svn: 289640

[X86][InstCombine] Handle demanded elements for operand of AVX-512 scalar floating point to integer conversion intrinsics.

llvm-svn: 289639

This change aims to unify and correct our logic for when we need to allow for
the possibility of the linker adding a TOC restoration instruction after a
call. This comes up in two contexts:

 1. When determining tail-call eligibility. If we make a tail call (i.e.
    directly branch to a function) then there is no place for the linker to add
    a TOC restoration.
 2. When determining when we need to add a nop instruction after a call.
    Likewise, if there is a possibility that the linker might need to add a
    TOC restoration after a call, then we need to put a nop after the call
    (the bl instruction).

First problem: We were using similar, but different, logic to decide (1) and
(2). This is just wrong. Both the resideInSameModule function (used when
determining tail-call eligibility) and the isLocalCall function (used when
deciding if the post-call nop is needed) were supposed to be determining the
same underlying fact (i.e. might a TOC restoration be needed after the call).
The same logic should be used in both places.

Second problem: The logic in both places was wrong. We only know that two
functions will share the same TOC when both functions come from the same
section of the same object. Otherwise the linker might cause the functions to
use different TOC base addresses (unless the multi-TOC linker option is
disabled, in which case only shared-library boundaries are relevant). There are
a number of factors that can cause functions to be placed in different sections
or come from different objects (-ffunction-sections, explicitly-specified
section names, COMDAT, weak linkage, etc.). All of these need to be checked.
The existing logic only checked properties of the callee, but the properties of
the caller must also be checked (for example, calling from a function in a
COMDAT section means calling between sections).

There was a conceptual error in the resideInSameModule function in that it
allowed tail calls to functions with weak linkage and protected/hidden
visibility. While protected/hidden visibility does prevent the function
implementation from being replaced at runtime (via interposition), it does not
prevent the linker from using an alternate implementation at link time (i.e.
using some strong definition to replace the provided weak one during linking).
If this happens, then we're still potentially looking at a required TOC
restoration upon return.

Otherwise, in general, the post-call nop is needed wherever ELF interposition
needs to be supported. We don't currently support ELF interposition at the IR
level (see http://lists.llvm.org/pipermail/llvm-dev/2016-November/107625.html
for more information), and I don't think we should try to make it appear to
work in the backend in spite of that fact. This will yield subtle bugs if
interposition is attempted. As a result, regardless of whether we're in PIC
mode, we don't assume that we need to add the nop to support the possibility of
ELF interposition. However, the necessary check is in place (i.e. calling
GV->isInterposable and TM.shouldAssumeDSOLocal) so when we have functions for
which interposition is allowed at the IR level, we'll add the nop as necessary.
In the mean time, we'll generate more tail calls and fewer nops when compiling
position-independent code.

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

llvm-svn: 289638

Reviewers: alexfh

Subscribers: JDevlieghere, cfe-commits

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

llvm-svn: 289637

[X86][InstCombine] Teach SimplifyDemandedVectorElts to handle masked scalar add/sub/mul/div/max/min intrinsics better.

Now we can remove these intrinsics if element 0 isn't used. Also fix undef element tracking.

llvm-svn: 289636

Now we pass a modified version of DemandedElts to each operand and we calculate undef elts correctly.

llvm-svn: 289632

Summary:
The motivation is to support better the -object_path_lto option on
Darwin. The linker needs to write down the generate object files on
disk for later use by lldb or dsymutil (debug info are not present
in the final binary). We're moving this into libLTO so that we can
be smarter when a cache is enabled and hard-link when possible
instead of duplicating the files.

Reviewers: tejohnson, deadalnix, pcc

Subscribers: dexonsmith, llvm-commits

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

llvm-svn: 289631

llvm-svn: 289630

[X86][InstCombine] Teach SimplifyDemandedVectorElts to handle scalar round intrinsics more correctly.

Now we only pass bit 0 of the DemandedElts to optimize operand 1 as we recurse since the upper bits are unused. Similarly we clear bit 0 for optimizing operand 0.

Also calculate UndefElts correctly.

Simplify InstCombineCalls for these instrinics to just call SimplifyDemandedVectorElts for the call instrution to reuse this support.

llvm-svn: 289629

[X86][InstCombine] Teach SimplifyDemandedVectorElts to handle scalar min/max/cmp intrinsics more correctly.

Now we only pass bit 0 of the DemandedElts to optimize operand 1 as we recurse since the upper bits are unused.

Also calculate UndefElts correctly.

Simplify InstCombineCalls for these instrinics to just call SimplifyDemandedVectorElts for the call instrution to reuse this support.

llvm-svn: 289628

Summary:
This checks for calls to double-precision math.h with single-precision
arguments.  For example, it suggests replacing ::sin(0.f) with
::sinf(0.f).

Subscribers: mgorny, cfe-commits

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

llvm-svn: 289627

Don't double-initialize cl::opt for iterating in reverse order to uncover non-determinism in codegen by default

Bots are broken and needs to be fixed before having this on by default.
The feature was committed in r289619.

I tried to disable it in r289624 and failed because it was initialized in two places.

llvm-svn: 289626

In r267772, we had set the PS4's default dialect for both C and
Objective-C to gnu99.  Make that change only for C; we don't really
support Objective-C/C++ so there's no point fiddling the dialect.

llvm-svn: 289625

Bots are broken and needs to be fixed before having this on by default.
The feature was committed in r289619.

llvm-svn: 289624

cleanup loop for exception handling.

llvm-svn: 289623

llvm-svn: 289622

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

llvm-svn: 289621

Follow-up to r289256, address a FIXME to avoid resetting the column
number. This reduced .debug_line by 2.6% in a RelWithDebInfo
self-build of clang.

llvm-svn: 289620

Summary:
Given a flag (-mllvm -reverse-iterate) this patch will enable iteration of SmallPtrSet in reverse order.
The idea is to compile the same source with and without this flag and expect the code to not change.
If there is a difference in codegen then it would mean that the codegen is sensitive to the iteration order of SmallPtrSet.
This is enabled only with LLVM_ENABLE_ABI_BREAKING_CHECKS.

Reviewers: chandlerc, dexonsmith, mehdi_amini

Subscribers: mgorny, emaste, llvm-commits

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

llvm-svn: 289619

copy constructors of classes with array members, instead using
ArrayInitLoopExpr to represent the initialization loop.

This exposed a bug in the static analyzer where it was unable to differentiate
between zero-initialized and unknown array values, which has also been fixed
here.

llvm-svn: 289618

llvm-svn: 289617

fragile runtime too.

Follow-up to r258962.

rdar://problem/29269006

llvm-svn: 289615

llvm-svn: 289614

llvm-svn: 289613

llvm-svn: 289612

Switch functions that returned bool and filled in a DWARFFormValue arg with ones that return Optional<DWARFFormValue>

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

llvm-svn: 289611

llvm-svn: 289610

We shouldn't print the dylib if LinkDylib is false.

llvm-svn: 289609

Summary:
LinkDyLib is only used (before arg processing) to set up the default for
LinkMode. So reset LinkMode as well, and process before --link-shared or
--link-static to allow those flags to continue to override it.

Reviewers: beanz

Subscribers: llvm-commits

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

llvm-svn: 289608

[libFuzzer] fix an UB (invalid shift) spotted by ubsan. The code worked fine by luck, because the way shifts actually work on clang+x86

llvm-svn: 289607

llvm-svn: 289606

This flag forces off linking libLLVM. This should resolve some issues reported on llvm-commits.

llvm-svn: 289605

llvm-svn: 289604

Change CoverageTracker from a global variable to member variable to avoid breaking thread-safety. (NFC)

llvm-svn: 289603

This change re-lands r289215, by reverting r289482.  The underlying
issue that caused it to be reverted has been fixed by Tim Northover in
r289496.

Original commit message for r289215:

[SCEVExpander] Use llvm data structures; NFC

Original commit message for r289482:

Revert "[SCEVExpander] Use llvm data structures; NFC"

This reverts r289215 (git SHA1 cb7b86a1).  It breaks the ubsan build
because a DenseMap that keys off of `AssertingVH<T>` will hit UB when it
tries to cast the empty and tombstone keys to `T *` (due to insufficient
alignment).

This is the relevant stack trace (thanks to Mike Aizatsky):

    #0 0x25cf100 in llvm::AssertingVH<llvm::PHINode>::getValPtr() const llvm/include/llvm/IR/ValueHandle.h:212:39
    #1 0x25cea20 in llvm::AssertingVH<llvm::PHINode>::operator=(llvm::AssertingVH<llvm::PHINode> const&) llvm/include/llvm/IR/ValueHandle.h:234:19
    #2 0x25d0092 in llvm::DenseMapBase<llvm::DenseMap<llvm::AssertingVH<llvm::PHINode>, llvm::detail::DenseSetEmpty, llvm::DenseMapInfo<llvm::AssertingVH<llvm::PHINode> >, llvm::detail::DenseSetPair<llvm::AssertingVH<llvm::PHINode> > >, llvm::AssertingVH<llvm::PHINode>, llvm::detail::DenseSetEmpty, llvm::DenseMapInfo<llvm::AssertingVH<llvm::PHINode> >, llvm::detail::DenseSetPair<llvm::AssertingVH<llvm::PHINode> > >::clear() llvm/include/llvm/ADT/DenseMap.h:113:23

llvm-svn: 289602