Summary:
This diff attempts to address the concerns raised in
http://reviews.llvm.org/D12488.

We introduce a new USE_SHARED option to llvm_config,
which, if set, causes the target to be linked against
libLLVM.

add_llvm_utility now uniformly disables linking against
libLLVM. These utilities are not intended for distribution,
and this keeps the option handling more centralised.

llvm-shlib is now processes before any other "tools"
subdirectories, ensuring the libLLVM target is defined
before its dependents.

One main difference from what was requested: llvm_config
does not prune LLVM_DYLIB_COMPONENTS from the components
passed into explicit_llvm_config. This is because the "all"
component does something special, adding additional
libraries (namely libLTO). Adding the component libraries
after libLLVM should not be a problem, as symbols will be
resolved in libLLVM first.

Finally, I'm not really happy with the
DISABLE_LLVM_LINK_LLVM option, but I'm not sure of a
better way to get the following:
 - link all tools and shared libraries to libLLVM if
   LLVM_LINK_LLVM_DYLIB is set
 - some way of explicitly *not* doing so for utilities
   and libLLVM itself
Suggestions for improvement here are particularly welcome.

Reviewers: beanz

Subscribers: llvm-commits

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

llvm-svn: 246918

llvm-svn: 246908

We want a deterministic output. GNU AS leaves it zero.

FIXME: It may be optional by its user, like llc and clang.
llvm-svn: 246905

This commit accomplish two goals:
1) it's a step forward to deprecate macho-dump, now less than 40 tests
rely on it.

2) It tests all the MachO specific features introduced in llvm-readobj in
the following commits:  r246789, r246665, r246474.

While the conversion is mostly mechanical (I double-checked all the
tests output one by one, but still), a post-commit review is greatly
appreciated.

llvm-svn: 246904

llvm-svn: 246903

PPCISelDAGToDAG has a transformation that generates a rlwimi instruction from
an input pattern that looks like this:

  and(or(x, c1), c2)

but the associated logic does not work if there are bits that are 1 in c1 but 0
in c2 (these are normally canonicalized away, but that can't happen if the 'or'
has other users. Make sure we abort the transformation if such bits are
discovered.

Fixes PR24704.

llvm-svn: 246900

llvm-svn: 246899

The variable is actually called ANDROID_SERIAL.
This was not exercised on the bots until today.
Should fix the sanitizer-x86_64-linux failures.

llvm-svn: 246898

llvm-svn: 246897

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

llvm-svn: 246896

llvm-svn: 246888

This was found while converting a test from macho-dump to llvm-readobj
and will once I commit the converted test.

llvm-svn: 246868

llvm-svn: 246865

llvm-svn: 246863

llvm-svn: 246862

Also, test commit

llvm-svn: 246855

llvm-svn: 246851

llvm-svn: 246848

Casting to unsigned long can cause the time to get truncated to 32-bits,
making it appear to be a valid timestamp.  Just use isUInt<32> instead.

llvm-svn: 246840

llvm-svn: 246839

should, rather than giving a broken value that doesn't even zero/sign-extend
properly.

llvm-svn: 246836

Using generic neon syntax to avoid test failure on apple platforms.

llvm-svn: 246833

[libFuzzer] when a single mutation fails try a few more times with other mutations before returning un-mutated data

llvm-svn: 246828

llvm-svn: 246825

This adds a basic cost model for interleaved-access vectorization (and a better
default for shuffles), and enables interleaved-access vectorization by default.
The relevant difference from the default cost model for interleaved-access
vectorization, is that on PPC, the shuffles that end up being used are *much*
cheaper than modeling the process with insert/extract pairs (which are
quite expensive, especially on older cores).

llvm-svn: 246824

On the A2, with an eye toward QPX unaligned-load merging, we should always use
aggressive interleaving. It is generally superior to only using concatenation
unrolling.

llvm-svn: 246819

When forming permutation-based unaligned vector loads, we need to know whether
it is valid to read ahead of the requested address by a full vector length.
Doing so is more efficient (and allows for more CSE with later loads), but
could trigger a page fault if invalid. To determine validity, we look for other
loads in the same block that access the relevant address range.

The relevant point here is that we need to do this as part of the process of
forming permutation-based vector loads, and this happens quite early in the
SDAG pipeline - specifically before many of the address calculations are fully
canonicalized. As a result, we need to try harder to recognize base+offset
address computations, because they still might appear as chain of adds
(base+offset+offset, for example). To account for this, we'll look through
chains of adds, accumulating the constant offsets.

llvm-svn: 246813

Test case attached -- currently the parser smears the "foo bar" to all
of the formal arguments.

llvm-svn: 246812

llvm-svn: 246810

As a first step towards a new implementation of the base pointer inference algorithm, introduce an abstraction for BDVs, strengthen the assertions around them, and rewrite the BDV relation code in terms of the abstraction which includes an explicit notion of whether the BDV is also a base. The later is motivated by the fact we had a bug where insertelement was always assumed to be a base pointer even though the BDV code knew it wasn't. The strengthened assertions in this patch would have caught that bug.

The next step will be to separate the DefiningValueMap into a BDV use list cache (entirely within findBasePointers) and a base pointer cache. Having the former will allow me to use a deterministic visit order when visiting BDVs in the inference algorithm and remove a bunch of ordering related hacks. Before actually doing the last step, I'm likely going to extend the lattice with a 'BaseN' (seen only base inputs) state so that I can kill the post process optimization step.

Phabricator Revision: http://reviews.llvm.org/D12608

llvm-svn: 246809

llvm-svn: 246808

Pre-P8, when we generate code for unaligned vector loads (for Altivec and QPX
types), even when accounting for the combining that takes place for multiple
consecutive such loads, there is at least one load instructions and one
permutation for each load. Make sure the cost reported reflects the cost of the
permutes as well.

llvm-svn: 246807

If you compute the MMO offset using unsigned arithmetic, you end up with a
large positive offset instead of a small negative one. In theory, this could
cause bad instruction-scheduling decisions later.

I noticed this by inspection from the debug output, and using that for the
regression test is the best I can do right now.

llvm-svn: 246805

The visit order being used in the base pointer inference algorithm is currently non-deterministic.  When working on http://reviews.llvm.org/D12583, I discovered that we were relying on a peephole optimization to get deterministic ordering in one of the test cases.  

This change is intented to let me test and land http://reviews.llvm.org/D12583.  The current code will not be long lived.  I'm starting to investigate a rewrite of the algorithm which will combine the post-process step into the initial algorithm and make the visit order determistic.  Before doing that, I wanted to make sure the existing code was complete and the test were stable.  Hopefully, patches should be up for review for the new algorithm this week or early next.

llvm-svn: 246801

llvm-svn: 246800

Splitting basic blocks really messes up WinEHPrepare. We can remove this
change when SEH uses the new EH IR.

llvm-svn: 246799

llvm-svn: 246798

* ``the value cannot fit within the destination type`` is ambiguous.
  It could mean overflow, underflow (not in the IEEE-754 sense) or a
  result that cannot be exactly represented and requires rounding or it
  could mean some combination of these. The semantics now state it means
  overflow **only**.

* Using "truncation" in the semantics is very misleading given that it
  doesn't necessarily truncate (i.e. round to zero). For example on
  x86_64 with SSE2 this is currently mapped to cvtsd2ss instruction
  who's rounding behaviour is dependent on the MXCSR register which
  is usually set to round to nearest even by default. The semantics
  now state that the rounding mode is undefined.

llvm-svn: 246792

In vectorized add reduction code, the final "reduce" step is sub-optimal.
This change wll combine :

ext  v1.16b, v0.16b, v0.16b, #8
add  v0.4s, v1.4s, v0.4s
dup  v1.4s, v0.s[1]
add  v0.4s, v1.4s, v0.4s

into

addv s0, v0.4s

PR21371
http://reviews.llvm.org/D12325
Patch by Jun Bum Lim <junbuml@codeaurora.org>!

llvm-svn: 246790

Example output:

File: <stdin>
Format: Mach-O 32-bit i386
Arch: i386
AddressSize: 32bit
Indirect Symbols {

Number: 3
Symbols [
  Entry {
    Entry Index: 0
    Symbol Index: 0x4
  }
  Entry {
    Entry Index: 1
    Symbol Index: 0x0
  }
  Entry {
    Entry Index: 2
    Symbol Index: 0x1
  }
]
}

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

llvm-svn: 246789