BitcodeTests: Fix LINK_COMPONENTS.

git-svn-id: http://llvm.org/svn/llvm-project/llvm/trunk@214598 91177308-0d34-0410-b5e6-96231b3b80d8
Add diagnostics to the vectorizer cost model.

When the cost model determines vectorization is not possible/profitable these remarks print an analysis of that decision.

Note that in selectVectorizationFactor() we can assume that OptForSize and ForceVectorization are mutually exclusive.

Reviewed by Arnold Schwaighofer


git-svn-id: http://llvm.org/svn/llvm-project/llvm/trunk@214599 91177308-0d34-0410-b5e6-96231b3b80d8
[SDAG] Let the DAG combiner take care of dead nodes rather than manually
deleting them. This already seems to work, as no tests fail without
this.

git-svn-id: http://llvm.org/svn/llvm-project/llvm/trunk@214601 91177308-0d34-0410-b5e6-96231b3b80d8
[SDAG] Allow the legalizer to delete an illegally typed intermediate
introduced during legalization. This pattern is based on other patterns
in the legalizer that I changed in the same way. Now, the legalizer
eagerly collects its garbage when necessary so that we can survive
leaving such nodes around for it.

Instead, we add an assert to make sure the node will be correctly
handled by that layer.

git-svn-id: http://llvm.org/svn/llvm-project/llvm/trunk@214602 91177308-0d34-0410-b5e6-96231b3b80d8
[ASan] Use metadata to pass source-level information from Clang to ASan.

Instead of creating global variables for source locations and global names,
just create metadata nodes and strings. They will be transformed into actual
globals in the instrumentation pass (if necessary). This approach is more
flexible:
1) we don't have to ensure that our custom globals survive all the optimizations
2) if globals are discarded for some reason, we will simply ignore metadata for them
   and won't have to erase corresponding globals
3) metadata for source locations can be reused for other purposes: e.g. we may
   attach source location metadata to alloca instructions and provide better descriptions
   for stack variables in ASan error reports.

No functionality change.


git-svn-id: http://llvm.org/svn/llvm-project/llvm/trunk@214604 91177308-0d34-0410-b5e6-96231b3b80d8
[x86] Make some questionable tests not spew assembly to stdout, which
makes a mess of the lit output when they ultimately fail.

The 2012-10-02-DAGCycle test is really frustrating because the *only*
explanation for what it is testing is a rdar link. I would really rather
that rdar links (which are not public or part of the open source
project) were not committed to the source code. Regardless, the actual
problem *must* be described as the rdar link is completely opaque. The
fact that this test didn't check for any particular output further
exacerbates the inability of any other developer to debug failures.

The mem-promote-integers test has nice comments and *seems* to be
a great test for our lowering... except that we don't actually check
that any of the generated code is correct or matches some pattern. We
just avoid crashing. It would be great to go back and populate this test
with the actual expectations.

git-svn-id: http://llvm.org/svn/llvm-project/llvm/trunk@214605 91177308-0d34-0410-b5e6-96231b3b80d8
R600/SI: Fix formatting.

Avoid weird line wrapping of BuildMI dest register.

git-svn-id: http://llvm.org/svn/llvm-project/llvm/trunk@214608 91177308-0d34-0410-b5e6-96231b3b80d8
[lit] Add --show-xfail flag to LIT.

Summary:
This patch add a --show-xfail flag. If this flag is specified then each xfail test will be printed to output.
When it is not given xfail tests are ignored. Ignoring xfail tests is the current behavior.

This flag is meant to mirror the --show-unsupported flag that was recently added.

Reviewers: ddunbar, EricWF

Reviewed By: EricWF

Subscribers: llvm-commits

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

git-svn-id: http://llvm.org/svn/llvm-project/llvm/trunk@214609 91177308-0d34-0410-b5e6-96231b3b80d8
Add a small utility called bisect that enables commandline bisecting on a counter.

This is something that I have found to be very useful in my work and I
wanted to contribute it back to the community since several people in
the past have asked me for something along these lines. (Jakob, I know
this has been a while coming ; )]

The way you use this is you create a script that takes in as its first
argument a count. The script passes into LLVM the count via a command
line flag that disables a pass after LLVM has run after the pass has
run for count number of times. Then the script invokes a test of some
sort and indicates whether LLVM successfully compiled the test via the
scripts exit status. Then you invoke bisect as follows:

bisect --start=<start_num> --end=<end_num> ./script.sh "%(count)s"

And bisect will continually call ./script.sh with various counts using
the exit status to determine success and failure.

git-svn-id: http://llvm.org/svn/llvm-project/llvm/trunk@214610 91177308-0d34-0410-b5e6-96231b3b80d8
R600: Cleanup fneg tests

git-svn-id: http://llvm.org/svn/llvm-project/llvm/trunk@214612 91177308-0d34-0410-b5e6-96231b3b80d8
[MCJIT] Fix an overly-aggressive check in RuntimeDyldMachOARM.

This should fix the MachO_ARM_PIC_relocations.s test failures on some 32-bit
testers.



git-svn-id: http://llvm.org/svn/llvm-project/llvm/trunk@214613 91177308-0d34-0410-b5e6-96231b3b80d8
[ARM] In dynamic-no-pic mode, ARM's post-RA pseudo expansion was incorrectly
expanding pseudo LOAD_STATCK_GUARD using instructions that are normally used
in pic mode. This patch fixes the bug.

<rdar://problem/17886592>


git-svn-id: http://llvm.org/svn/llvm-project/llvm/trunk@214614 91177308-0d34-0410-b5e6-96231b3b80d8
CodeGen: Remove commented out code

These two lines have been commented out for over 4 years. They aren't
helping anyone.

git-svn-id: http://llvm.org/svn/llvm-project/llvm/trunk@214615 91177308-0d34-0410-b5e6-96231b3b80d8
Fix issues with ISD::FNEG and ISD::FMA SDNodes where they would not be constant-folded
during DAGCombine in certain circumstances.  Unfortunately, the circumstances required
to trigger the issue seem to require a pretty specific interaction of DAGCombines,
and I haven't been able to find a testcase that reproduces on X86, ARM, or AArch64.
The functionality added here is replicated in essentially every other DAG combine,
so it seems pretty obviously correct.



git-svn-id: http://llvm.org/svn/llvm-project/llvm/trunk@214622 91177308-0d34-0410-b5e6-96231b3b80d8
[SDAG] Refactor the code which deletes nodes in the DAG combiner to do
so using a single helper which adds operands back onto the worklist.

Several places didn't rigorously do this but a couple already did.
Factoring them together and doing it rigorously is important to delete
things recursively early on in the combiner and get a chance to see
accurate hasOneUse values. While no existing test cases change, an
upcoming patch to add DAG combining logic for PSHUFB requires this to
work correctly.

git-svn-id: http://llvm.org/svn/llvm-project/llvm/trunk@214623 91177308-0d34-0410-b5e6-96231b3b80d8
[x86] Teach my pshufb comment printer to handle VPSHUFB forms as well as
PSHUFB forms. This will be important to update some AVX tests when I add
PSHUFB combining.

git-svn-id: http://llvm.org/svn/llvm-project/llvm/trunk@214624 91177308-0d34-0410-b5e6-96231b3b80d8
[x86] Teach the target shuffle mask extraction to recognize unary forms
of normally binary shuffle instructions like PUNPCKL and MOVLHPS.

This detects cases where a single register is used for both operands
making the shuffle behave in a unary way. We detect this and adjust the
mask to use the unary form which allows the existing DAG combine for
shuffle instructions to actually work at all.

As a consequence, this uncovered a number of obvious bugs in the
existing DAG combine which are fixed. It also now canonicalizes several
shuffles even with the existing lowering. These typically are trying to
match the shuffle to the domain of the input where before we only really
modeled them with the floating point variants. All of the cases which
change to an integer shuffle here have something in the integer domain, so
there are no more or fewer domain crosses here AFAICT. Technically, it
might be better to go from a GPR directly to the floating point domain,
but detecting floating point *outputs* despite integer inputs is a lot
more code and seems unlikely to be worthwhile in practice. If folks are
seeing domain-crossing regressions here though, let me know and I can
hack something up to fix it.

Also as a consequence, a bunch of missed opportunities to form pshufb
now can be formed. Notably, splats of i8s now form pshufb.
Interestingly, this improves the existing splat lowering too. We go from
3 instructions to 1. Yes, we may tie up a register, but it seems very
likely to be worth it, especially if splatting the 0th byte (the
common case) as then we can use a zeroed register as the mask.

git-svn-id: http://llvm.org/svn/llvm-project/llvm/trunk@214625 91177308-0d34-0410-b5e6-96231b3b80d8
[x86] Fix a few typos in my comments spotted in passing.

git-svn-id: http://llvm.org/svn/llvm-project/llvm/trunk@214626 91177308-0d34-0410-b5e6-96231b3b80d8
[x86] Switch to using the variable we extracted this operand into.

Spotted this missed refactoring by inspection when reading code, and it
doesn't changethe functionality at all.

git-svn-id: http://llvm.org/svn/llvm-project/llvm/trunk@214627 91177308-0d34-0410-b5e6-96231b3b80d8
[x86] Largely complete the use of PSHUFB in the new vector shuffle
lowering with a small addition to it and adding PSHUFB combining.

There is one obvious place in the new vector shuffle lowering where we
should form PSHUFBs directly: when without them we will unpack a vector
of i8s across two different registers and do a potentially 4-way blend
as i16s only to re-pack them into i8s afterward. This is the crazy
expensive fallback path for i8 shuffles and we can just directly use
pshufb here as it will always be cheaper (the unpack and pack are
two instructions so even a single shuffle between them hits our
three instruction limit for forming PSHUFB).

However, this doesn't generate very good code in many cases, and it
leaves a bunch of common patterns not using PSHUFB. So this patch also
adds support for extracting a shuffle mask from PSHUFB in the X86
lowering code, and uses it to handle PSHUFBs in the recursive shuffle
combining. This allows us to combine through them, combine multiple ones
together, and generally produce sufficiently high quality code.

Extracting the PSHUFB mask is annoyingly complex because it could be
either pre-legalization or post-legalization. At least this doesn't have
to deal with re-materialized constants. =] I've added decode routines to
handle the different patterns that show up at this level and we dispatch
through them as appropriate.

The two primary test cases are updated. For the v16 test case there is
still a lot of room for improvement. Since I was going through it
systematically I left behind a bunch of FIXME lines that I'm hoping to
turn into ALL lines by the end of this.

git-svn-id: http://llvm.org/svn/llvm-project/llvm/trunk@214628 91177308-0d34-0410-b5e6-96231b3b80d8