IR: Optimize size of use-list order shuffle vectors

Since we're storing lots of these, save two-pointers per vector with a
custom type rather than using the relatively heavy `SmallVector`.

Part of PR5680.

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

[Debug Info] add DISubroutineType and its creation takes DITypeArray.

DITypeArray is an array of DITypeRef, at its creation, we will create
DITypeRef (i.e use the identifier if the type node has an identifier).

This is the last patch to unique the type array of a subroutine type.

rdar://17628609

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

Update LLVM version: 3.5 => 3.6

We branched 3.5, it's now time to work on 3.6.

This is Sylvestre's patch from [1] plus regenerated configure
file by me, and minus the release notes reset, which Sean
pointed out [2] should happen later.

 1. http://reviews.llvm.org/D4660
 2. http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20140721/111137.html

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

Regenerate autoconf, previous updates to the configury haven't
been updating configure.

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

llvm-uselistorder: Get it building in configure+make after r214125

Somehow this wasn't being built before (only noticed now since the test
was XFAILed).

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

Bitcode: Serialize (and recover) use-list order

Predict and serialize use-list order in bitcode.  This makes the option
`-preserve-bc-use-list-order` work *most* of the time, but this is still
experimental.

  - Builds a full value-table up front in the writer, sets up a list of
    use-list orders to write out, and discards the table.  This is a
    simpler first step than determining the order from the various
    overlapping IDs of values on-the-fly.

  - The shuffles stored in the use-list order list have an unnecessarily
    large memory footprint.

  - `blockaddress` expressions cause functions to be materialized
    out-of-order.  For now I've ignored this problem, so use-list orders
    will be wrong for constants used by functions that have block
    addresses taken.  There are a couple of ways to fix this, but I
    don't have a concrete plan yet.

  - When materializing functions lazily, the use-lists for constants
    will not be correct.  This use case is out of scope: what should the
    use-list order be, if it's incomplete?

This is part of PR5680.

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

llvm-uselistorder: Add -save-temps option

This is part of PR5680.

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

llvm-uselistorder: Check the correct flag for assembly

This is part of PR5680.

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

IR: Expose Module::rbegin() and rend()

A follow-up commit for PR5680 needs to visit functions in reverse order.
Expose iterators to allow that.

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

[MCJIT] Remove extraneous parentheses in test case.

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

Test the linker plugin handling of llvm.used.

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

[Debug Info] add a template class DITypedArray.

Typedef DIArray to DITypedArray<DIDescriptor>. Also typedef DITypeArray as
DITypedArray<DITypeRef>.

This is the third of a series of patches to handle type uniqueing of the
type array for a subroutine type.

This commit should have no functionality change.

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

[Debug Info] rename getTypeArray to getElements, setTypeArray to setArrays.

This is the second of a series of patches to handle type uniqueing of the
type array for a subroutine type.

For vector and array types, getElements returns the array of subranges, so it
is a better name than getTypeArray. Even for class, struct and enum types,
getElements returns the members, which can be subprograms.

setArrays can set up to two arrays, the second is the templates.

This commit should have no functionality change.

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

[Debug Info] replace DIUnspecifiedParameter with DITrivialType.

This is the first of a series of patches to handle type uniqueing of the
type array for a subroutine type.

This commit makes sure unspecified_parameter is a DIType to enable converting
the type array for a subroutine type to an array of DITypes.

This commit should have no functionality change. With this commit, we may
change unspecified type to be a DITrivialType instead of a DIType.

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

R600: Modernize test

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

llvm-cov: move the gcov code into a separate file.

The gcov compatible code is moved to its own file and
llvm-cov is updated to be a wrapper that always calls
the gcov main function.

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

R600/SI: Fix return type for isMIMG / isSMRD

All the others use bool, so these should too.

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

[SDAG] Add DEBUG logging to the legalizer, fixing a "bug" found by
inspection in the proccess, and shuffle the logging in the DAG combiner
around a bit.

With this it is much easier to follow what the legalizer is doing. It
should even accurately present most of the strange legalization
operations where a single node is replaced by multiple nodes, etc. There
is still some information lost (we log SDNodes not SDValues so we don't
log which result is used for which thing), but I think this is much
closer to a usable system. Notably, this will make it *much* more
apparant when legalization is actually happening inside the combiner, or
when there is a cycle caused by interactions of the legalizer and the
combiner.

The "bug" I fixed here I'm not sure is remotely possible to trigger. We
were only adding one of the nodes in a replacement to the updated set
rather than all of the nodes in the replacement. Realistically, the
worst result of this are nodes not getting back onto the worklist in the
DAG combiner. I doubt it is possible to trigger this today, and
I certainly don't have any ideas about how, but this at least brings the
code into alignment with the principled operation of the routine.

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

R600/SI: Implement getOptimalMemOpType

The default guess uses i32. This needs an address space argument
to really do the right thing in all cases.

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

Add tests for the various emit-llvm plugin options.

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

R600/SI: Make argument loads invariant

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

Update comment

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

Test the mcpu option.

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

[SKX] Enabling mask logic instructions: encoding, lowering
Instructions: KAND{BWDQ}, KANDN{BWDQ}, KOR{BWDQ}, KXOR{BWDQ}, KXNOR{BWDQ}

Reviewed by Elena Demikhovsky <elena.demikhovsky@intel.com>

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

Emit a warning if llvm_map_components_to_libraries() is used noting that its
use is deprecated in favour of llvm_map_components_to_libnames()

Although message(DEPRECATION "msg") would probably be a better fit this
does nothing if CMAKE_ERROR_DEPRECATED and CMAKE_WARNING_DEPRECATED are
both off, which is the default.

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

Document the new LLVM CMake interface for building against LLVM
libraries. With many contributions from Brad King.

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

Fixed sphinx warning.

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

[PowerPC] Add testcase forgotten in the 214072 commit.

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

[PowerPC] Support ELFv1/ELFv2 ABI selection via features

While LLVM now supports both ELFv1 and ELFv2 ABIs, their use is currently
hard-coded via the target triple: powerpc64-linux is always ELFv1, while
powerpc64le-linux is always ELFv2.

These are of course the most common scenarios, but in principle it is
possible to support the ELFv2 ABI on big-endian or the ELFv1 ABI on
little-endian systems (and GCC does support that), and there are some
special use cases for that (e.g. certain Linux kernel versions could
only be built using ELFv1 on LE).

This patch implements the LLVM side of supporting this.  As precedent
on other platforms suggests, ABI options are passed to the back-end as
features.  Thus, this patch implements two features "elfv1" and "elfv2"
that select the desired ABI if present.  (If not, the LLVM uses the
same default rules as now.)

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

Start adding some tests for the gold plugin.

These are only used when the 'ld' in the path is gold and the plugin has
been built, but it is already a start to make sure we don't regress features
that cannot be tested with llvm-lto.

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

ARM: correct handling of features in arch_extension

The subtarget information is the ultimate source of truth for the feature set
that is enabled at this point.  We would previously not propagate the feature
information to the subtarget.  While this worked for the most part (features
would be enabled/disabled as requested), if another operation that changed the
feature bits was encountered (such as a mode switch via a .arm or .thumb
directive), we would end up resetting the behaviour of the architectural
extensions.

Handling this properly requires a slightly more complicated handling.  We need
to check if the feature is now being toggled.  If so, only then do we toggle the
features.  In return, we no longer have to calculate the feature bits ourselves.

The test changes are mostly to the diagnosis, which is now more uniform (a nice
side effect!).  Add an additional test to ensure that we handle this case
properly.

Thanks to Nico Weber for alerting me to this issue!

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

ARM: convert loop to range based

Convert a loop to use range based iteration.  Rename structure members to help
naming, and make structure definition anonymous.  NFC.

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

Add alignment value to allowsUnalignedMemoryAccess

Rename to allowsMisalignedMemoryAccess.

On R600, 8 and 16 byte accesses are mostly OK with 4-byte alignment,
and don't need to be split into multiple accesses. Vector loads with
an alignment of the element type are not uncommon in OpenCL code.

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

AArch64: fix conversion of 'J' inline asm constraints.

'J' represents a negative number suitable for an add/sub alias
instruction, but while preparing it to become an int64_t we were
mangling the sign extension. So "i32 -1" became 0xffffffffLL, for
example.

Should fix one half of PR20456.

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

[x86] Sink a variable only used by asserts into the asserts. Should fix
some -Werror bots, sorry for the noise.

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

[x86] Add a much more powerful framework for combining x86 shuffle
instructions in the legalized DAG, and leverage it to combine long
sequences of instructions to PSHUFB.

Eventually, the other x86-instruction-specific shuffle combines will
probably all be driven out of this routine. But the real motivation is
to detect after we have fully legalized and optimized a shuffle to the
minimal number of x86 instructions whether it is profitable to replace
the chain with a fully generic PSHUFB instruction even though doing so
requires either a load from a constant pool or tying up a register with
the mask.

While the Intel manuals claim it should be used when it replaces 5 or
more instructions (!!!!) my experience is that it is actually very fast
on modern chips, and so I've gon with a much more aggressive model of
replacing any sequence of 3 or more instructions.

I've also taught it to do some basic canonicalization to special-purpose
instructions which have smaller encodings than their generic
counterparts.

There are still quite a few FIXMEs here, and I've not yet implemented
support for lowering blends with PSHUFB (where its power really shines
due to being able to zero out lanes), but this starts implementing real
PSHUFB support even when using the new, fancy shuffle lowering. =]

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

[ADT] Add a remarkbly useful little helper routine to ArrayRef for
checking whether the ArrayRef is equal to an explicit list of arguments.

This is particularly easy to implement even without variadic templates
because ArrayRef happens to be homogeneously typed. As a consequence we
can use a "clever" wrapper type and default arguments to capture in
a single method many arguments as well as *how many* arguments the user
specified.

Thanks to Dave Blaikie for helping me pull together this little helper.
Suggestions for how to improve or generalize it are of course welcome.
I'll be using it immediately in my follow-up patch. =D

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

R600/SI: Fix broken test.

There was no check prefix for the instruction lines.
Match what is emitted though, although I'm pretty sure it is
incorrect.

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

Fix the failing test 'vector-idiv.ll'.
On Darwin the comment character is ##.

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

R600: Move intrinsic lowering to separate functions

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

[SDAG] Add an assert that we don't mess up the number of values when
replacing nodes in the legalizer.

This caught a number of bugs for me during development.

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

[SDAG] Simplify the code for handling single-value nodes and add
a missing transfer of debug information (without which tests fail).

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

[SDAG] When performing post-legalize DAG combining, run the legalizer
over each node in the worklist prior to combining.

This allows the combiner to produce new nodes which need to go back
through legalization. This is particularly useful when generating
operands to target specific nodes in a post-legalize DAG combine where
the operands are significantly easier to express as pre-legalized
operations. My immediate use case will be PSHUFB formation where we need
to build a constant shuffle mask with a build_vector node.

This also refactors the relevant functionality in the legalizer to
support this, and updates relevant tests. I've spoken to the R600 folks
and these changes look like improvements to them. The avx512 change
needs to be investigated, I suspect there is a disagreement between the
legalizer and the DAG combiner there, but it seems a minor issue so
leaving it to be re-evaluated after this patch.

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

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

Fix broken assert.

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

X86ShuffleDecode.cpp: Silence a warning. [-Wunused-variable]

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

llvm/test/CodeGen/X86/vector-idiv.ll: Fix for -Asserts.

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

[x86] Fix PR20355 (for real). There are many layers to this bug.

The tale starts with r212808 which attempted to fix inversion of the low
and high bits when lowering MUL_LOHI. Sadly, that commit did not include
any positive test cases, and just removed some operations from a test
case where the actual logic being changed isn't fully visible from the
test.

What this commit did was two things. First, it reversed the low and high
results in the formation of the MERGE_VALUES node for the multiple
results. This is entirely correct.

Second it changed the shuffles for extracting the low and high
components from the i64 results of the multiplies to extract them
assuming a big-endian-style encoding of the multiply results. This
second change is wrong. There is no big-endian encoding in x86, the
results of the multiplies are normal v2i64s: when cast to v4i32, the low
i32s are at offsets 0 and 2, and the high i32s are at offsets 1 and 3.

However, the first change wasn't enough to actually fix the bug, which
is (I assume) why the second change was also made. There was another bug
in the MERGE_VALUES formation: we weren't using a VTList, and so were
getting a single result node! When grabbing the *second* result from the
node, we got... well.. colud be anything. I think this *appeared* to
invert things, but had to be causing other problems as well.

Fortunately, I fixed the MERGE_VALUES issue in r213931, so we should
have been fine, right? NOOOPE! Because the core bug was never addressed,
the test in vector-idiv failed when I fixed the MERGE_VALUES node.
Because there are essentially no docs for this node, I had to guess at
how to fix it and tried swapping the operands, restoring the order of
the original code before r212808. While this "fixed" the test case (in
that we produced the write instructions) we were still extracting the
wrong elements of the i64s, and thus PR20355 was still broken.

This commit essentially reverts the big-endian-style extraction part of
r212808 and goes back to the original masks which were correct. Now that
the MERGE_VALUES node formation is also correct, everything works. I've
also included a more detailed test from PR20355 to make sure this stays
fixed.

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

[x86] Finish switching from CHECK to ALL. This was mistakenly included
in r214007 and then reverted when I backed that (very misguided) patch
out. This recovers the test case cleanup which was good.

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

[x86] Revert r214007: Fix PR20355 ...

The clever way to implement signed multiplication with unsigned *is
already implemented* and tested and working correctly. The bug is
somewhere else. Re-investigating.

This will teach me to not scroll far enough to read the code that did
what I thought needed to be done.

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

[x86] Fix PR20355 (and dups) by not using unsigned multiplication when
signed multiplication is requested. While there is not a difference in
the *low* half of the result, the *high* half (used specifically to
implement the signed division by these constants) certainly is used. The
test case I've nuked was actively asserting wrong code.

There is a delightful solution to doing signed multiplication even when
we don't have it that Richard Smith has crafted, but I'll add the
machinery back and implement that in a follow-up patch. This at least
restores correctness.

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

[x86] Add coverage for PMUL* instruction testing on SSE2 as well as
SSE4.1.

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

[modules] Work around mislayering of MC / Object.

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

Update X86/Utils/LLVMBuild.txt corresponding to r213986. "Core" has been introduced.

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

IR/UseTest.cpp: Avoid std::to_string() to appease mingw32 bot.

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

[x86] More cleanup for this test -- simplify the command line.

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

[x86] Fix unused variable warning in no-asserts build.

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

[x86] FileCheck-ize this test.

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

[x86] Teach the X86 backend to print shuffle comments for PSHUFB
instructions which happen to have a constant mask.

Currently, this only handles a very narrow set of cases, but those
happen to be the cases that I care about for testing shuffles sanely.
This is a bit trickier than other shuffle instructions because we're
decoding constants out of the constant pool. The current MC layer makes
it completely impossible to inspect a constant pool entry, so we have to
do it at the MI level and attach the comment to the streamer on its way
out. So no joy for disassembling, but it does make test cases and asm
dumps *much* nicer.

Sorry for no test cases, but it didn't really seem that valuable to go
trolling through existing old test cases and updating them. I'll have
lots of testing of this in the upcoming patch for SSSE3 emission in the
new vector shuffle lowering code paths.

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

R600/SI: Allow partial unrolling and increase thresholds.

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

Move R600 subtarget dependent variables onto the subtarget.

No functional change.

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

coverage: remove empty mapping regions

This patch removes the empty coverage mapping regions.
Those regions were produced by clang's old mapping region generation
algorithm, but the new algorithm doesn't generate them.

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

Canonicalization for @llvm.assume

Adds simple logical canonicalization of assumption intrinsics to instcombine,
currently:
 - invariant(a && b) -> invariant(a); invariant(b)
 - invariant(!(a || b)) -> invariant(!a); invariant(!b)

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

Wrap to 80 columns, no behavior change.

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

llvm-uselistorder: Fix up LINK_COMPONENTS.

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

Add @llvm.assume, lowering, and some basic properties

This is the first commit in a series that add an @llvm.assume intrinsic which
can be used to provide the optimizer with a condition it may assume to be true
(when the control flow would hit the intrinsic call). Some basic properties are added here:

 - llvm.invariant(true) is dead.
 - llvm.invariant(false) is unreachable (this directly corresponds to the
   documented behavior of MSVC's __assume(0)), so is llvm.invariant(undef).

The intrinsic is tagged as writing arbitrarily, in order to maintain control
dependencies. BasicAA has been updated, however, to return NoModRef for any
particular location-based query so that we don't unnecessarily block code
motion.

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

[stack protector] Add test cases for thumb and thumb2.

<rdar://problem/12475629>

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

[stack protector] Fix a potential security bug in stack protector where the
address of the stack guard was being spilled to the stack.

Previously the address of the stack guard would get spilled to the stack if it
was impossible to keep it in a register. This patch introduces a new target
independent node and pseudo instruction which gets expanded post-RA to a
sequence of instructions that load the stack guard value. Register allocator
can now just remat the value when it can't keep it in a register.

<rdar://problem/12475629>

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

Fix arc4random detection.

Patch by Pascal Stumpf.

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

Remove dead code.

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

[PowerPC] Support TLS on PPC32/ELF

Patch by Justin Hibbits!

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

[FastISel][AArch64] Add support for frameaddress intrinsic.

This commit implements the frameaddress intrinsic for the AArch64 architecture
in FastISel.

There were two test cases that pretty much tested the same, so I combined them
to a single test case.

Fixes <rdar://problem/17811834>

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

Move -verify-use-list-order into llvm-uselistorder

Ugh.  Turns out not even transformation passes link in how to read IR.
I sincerely believe the buildbots will finally agree with my system
after this though.  (I don't really understand why all of this has been
working on my system, but not on all the buildbots.)

Create a new tool called llvm-uselistorder to use for verifying use-list
order.  For now, just dump everything from the (now defunct)
-verify-use-list-order pass into the tool.

This might be a better way to test use-list order anyway.

Part of PR5680.

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

Reapply "DebugInfo: Don't put fission type units in comdat sections."

This recommits r208930, r208933, and r208975 (by reverting r209338) and
reverts r209529 (the FIXME to readd this functionality once the tools
were fixed) now that DWP has been fixed to cope with a single section
for all fission type units.

Original commit message:

"Since type units in the dwo file are handled by a debug aware tool,
they don't need to leverage the ELF comdat grouping to implement
deduplication. Avoid creating all the .group sections for these as a
space optimization."

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

Claim AA generally as code owner

As per nominations from Chandler and Arnold.

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

Fix MSVC2012 build error in UseListOrder.cpp

I think the compiler got confused by the nested DEBUG macros.
It was failing with:

  UseListOrder.cpp(80) : error C2059: syntax error : '}'

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

Bitcode: Don't optimize constants when preserving use-list order

`ValueEnumerator::OptimizeConstants()` creates forward references within
the constant pools, which makes predicting constants' use-list order
difficult.  For now, just disable the optimization.

This can be re-enabled in the future in one of two ways:

  - Enable a limited version of this optimization that doesn't create
    forward references.  One idea is to categorize constants by their
    "height" and make that the top-level sort.

  - Enable it entirely.  This requires predicting how may times each
    constant will be recreated as its operands' and operands' operands'
    (etc.) forward references get resolved.

This is part of PR5680.

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

Recommit r212203: Don't try to construct debug LexicalScopes hierarchy for functions that do not have top level debug information.

Reverted by Eric Christopher (Thanks!) in r212203 after Bob Wilson
reported LTO issues. Duncan Exon Smith and Aditya Nandakumar helped
provide a reduced reproduction, though the failure wasn't too hard to
guess, and even easier with the example to confirm.

The assertion that the subprogram metadata associated with an
llvm::Function matches the scope data referenced by the DbgLocs on the
instructions in that function is not valid under LTO. In LTO, a C++
inline function might exist in multiple CUs and the subprogram metadata
nodes will refer to the same llvm::Function. In this case, depending on
the order of the CUs, the first intance of the subprogram metadata may
not be the one referenced by the instructions in that function and the
assertion will fail.

A test case (test/DebugInfo/cross-cu-linkonce-distinct.ll) is added, the
assertion removed and a comment added to explain this situation.

This was then reverted again in r213581 as it caused PR20367. The root
cause of this was the early exit in LiveDebugVariables meant that
spurious DBG_VALUE intrinsics that referenced dead variables were not
removed, causing an assertion/crash later on. The fix is to have
LiveDebugVariables strip all DBG_VALUE intrinsics in functions without
debug info as they're not needed anyway. Test case added to cover this
situation (that occurs when a debug-having function is inlined into a
nodebug function) in test/DebugInfo/X86/nodebug_with_debug_loc.ll

Original commit message:

If a function isn't actually in a CU's subprogram list in the debug info
metadata, ignore all the DebugLocs and don't try to build scopes, track
variables, etc.

While this is possibly a minor optimization, it's also a correctness fix
for an incoming patch that will add assertions to LexicalScopes and the
debug info verifier to ensure that all scope chains lead to debug info
for the current function.

Fix up a few test cases that had broken/incomplete debug info that could
violate this constraint.

Add a test case where this occurs by design (inlining a
debug-info-having function in an attribute nodebug function - we want
this to work because /if/ the nodebug function is then inlined into a
debug-info-having function, it should be fine (and will work fine - we
just stitch the scopes up as usual), but should the inlining not happen
we need to not assert fail either).

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

DebugInfo: Fix up some test cases to have more correct debug info metadata.

* Add CUs to the named CU node
* Add missing DW_TAG_subprogram nodes
* Add llvm::Functions to the DW_TAG_subprogram nodes

This cleans up the tests so that they don't break under a
soon-to-be-made change that is more strict about such things.

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

Add code owner of scoped-noalias metadata

Add myself as the code owner for the scoped-noalias metadata I've developed.

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

Convert noalias parameter attributes into noalias metadata during inlining

This functionality is currently turned off by default.

Part of the motivation for introducing scoped-noalias metadata is to enable the
preservation of noalias parameter attribute information after inlining.
Sometimes this can be inferred from the code in the caller after inlining, but
often we simply lose valuable information.

The overall process if fairly simple:
 1. Create a new unqiue scope domain.
 2. For each (used) noalias parameter, create a new alias scope.
 3. For each pointer, collect the underlying objects. Add a noalias scope for
    each noalias parameter from which we're not derived (and has not been
    captured prior to that point).
 4. Add an alias.scope for each noalias parameter from which we might be
    derived (or has been captured before that point).

Note that the capture checks apply only if one of the underlying objects is not
an identified function-local object.

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

Simplify and improve scoped-noalias metadata semantics

In the process of fixing the noalias parameter -> metadata conversion process
that will take place during inlining (which will be committed soon, but not
turned on by default), I have come to realize that the semantics provided by
yesterday's commit are not really what we want. Here's why:

void foo(noalias a, noalias b, noalias c, bool x) {
  *q = x ? a : b;
  *c = *q;
}

Generically, we know that *c does not alias with *a and with *b (so there is an
'and' in what we know we're not), and we know that *q might be derived from *a
or from *b (so there is an 'or' in what we know that we are). So we do not want
the semantics currently, where any noalias scope matching any alias.scope
causes a NoAlias return. What we want to know is that the noalias scopes form a
superset of the alias.scope list (meaning that all the things we know we're not
is a superset of all of things the other instruction might be).

Making that change, however, introduces a composibility problem. If we inline
once, adding the noalias metadata, and then inline again adding more, and we
append new scopes onto the noalias and alias.scope lists each time. But, this
means that we could change what was a NoAlias result previously into a MayAlias
result because we appended an additional scope onto one of the alias.scope
lists. So, instead of giving scopes the ability to have parents (which I had
borrowed from the TBAA implementation, but seems increasingly unlikely to be
useful in practice), I've given them domains. The subset/superset condition now
applies within each domain independently, and we only need it to hold in one
domain. Each time we inline, we add the new scopes in a new scope domain, and
everything now composes nicely. In addition, this simplifies the
implementation.

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

Try to fix a layering violation introduced by r213945

The dragonegg buildbot (and others?) started failing after
r213945/r213946 because `llvm-as` wasn't linking in the bitcode reader.
I think moving the verify functions to the same file as the verify pass
should fix the build.  Adding a command-line option for maintaining
use-list order in assembly as a drive-by to prevent warnings about
unused static functions.

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

Fix -Werror build after r213945

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

IPO: Add use-list-order verifier

Add a -verify-use-list-order pass, which shuffles use-list order, writes
to bitcode, reads back, and verifies that the (shuffled) order matches.

  - The utility functions live in lib/IR/UseListOrder.cpp.

  - Moved (and renamed) the command-line option to enable writing
    use-lists, so that this pass can return early if the use-list orders
    aren't being serialized.

It's not clear that this pass is the right direction long-term (perhaps
a separate tool instead?), but short-term it's a great way to test the
use-list order prototype.  I've added an XFAIL-ed testcase that I'm
hoping to get working pretty quickly.

This is part of PR5680.

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

[ARM] Emit ABI_PCS_R9_use build attribute.

Patch by Ben Foster!

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

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

Run sort_includes.py on the AArch64 backend.

No functionality change.

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

[cmake] Use the external project machinery for libcxxabi so that it can
be disabled in CMake or relocated if desired.

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

llvm/test/CodeGen/ARM/inlineasm-global.ll: Add explicit triple to appease targeting *-win32.

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

llvm/test/CodeGen/ARM/inlineasm-global.ll: Avoid specifing source file on llc.

It sometimes confuses FileCheck. Consider the case that path contains 'stmib'. :)

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

[SDAG] Enable the new assert for out-of-range result numbers in
SDValues, fixing the two bugs left in the regression suite.

The key for both of these was the use a single value type rather than
a VTList which caused an unintentionally single-result merge-value node.
Fix this by getting the appropriate VTList in place.

Doing this exposed that the comments in x86's code abouth how MUL_LOHI
operands are handle is wrong. The bug with the use of out-of-range
result numbers was hiding the bug about the order of operands here (as
best i can tell). There are more places where the code appears to get
this backwards still...

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

[SDAG] Don't insert the VRBase into a mapping from SDValues when the def
doesn't actually correspond to an SDValue at all. Fixes most of the
remaining asserts on out-of-range SDValue result numbers.

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

Store nodes only have 1 result.

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

[SDAG] Start plumbing an assert into SDValues that we don't form one
with a result number outside the range of results for the node.

I don't know how we managed to not really check this very basic
invariant for so long, but the code is *very* broken at this point.
I have over 270 test failures with the assert enabled. I'm committing it
disabled so that others can join in the cleanup effort and reproduce the
issues. I've also included one of the obvious fixes that I already
found. More fixes to come.

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

[ARM] In thumb mode, emit directive ".code 16" before file level inline
assembly instructions.

This is necessary to ensure ARM assembler switches to Thumb mode before it
starts assembling the file level inline assembly instructions at the beginning
of a .s file.

<rdar://problem/17757232>

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

[X86] Add comments to clarify some non-obvious lines in the stackmap-nops.ll
testcases.

Based on code review from Philip Reames. Thanks Philip!

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

llvm-vtabledump: use a std::map instead of a StringMap for VBTables

StringMap doesn't guarantee any particular iteration order,
this is suboptimal when comparing llvm-vtabledump's output for two
object files.

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

Fix a warning in CoverageMappingReader.cpp

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

[X86] Clarify some stackmap shadow optimization code as based on review
feedback from Eric Christopher.

No functional change.

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

[PATCH][PPC64LE] Correct little-endian usage of vmrgh* and vmrgl*.

Because the PowerPC vmrgh* and vmrgl* instructions have a built-in
big-endian bias, it is necessary to swap their inputs in little-endian
mode when using them to implement a vector shuffle.  This was
previously missed in the vector LE implementation.

There was already logic to distinguish between unary and "normal"
vmrg* vector shuffles, so this patch extends that logic to use a third
option:  "swapped" vmrg* vector shuffles that are used for little
endian in place of the "normal" ones.

I've updated the vec-shuffle-le.ll test to check for the expected
register ordering on the generated instructions.

This bug was discovered when testing the LE and ELFv2 patches for
safety if they were backported to 3.4.  A different vectorization
decision was made in 3.4 than on mainline trunk, and that exposed the
problem.  I've verified this fix takes care of that issue.

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

Add code coverage mapping data, reader, and writer.

This patch implements the data structures, the reader and
the writers for the new code coverage mapping system.
The new code coverage mapping system uses the instrumentation
based profiling to provide code coverage analysis.

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