[SROA] Teach SROA to be more aggressive in splitting now that we have
a pre-splitting pass over loads and stores.

Historically, splitting could cause enough problems that I hamstrung the
entire process with a requirement that splittable integer loads and
stores must cover the entire alloca. All smaller loads and stores were
unsplittable to prevent chaos from ensuing. With the new pre-splitting
logic that does load/store pair splitting I introduced in r225061, we
can now very nicely handle arbitrarily splittable loads and stores. In
order to fully benefit from these smarts, we need to mark all of the
integer loads and stores as splittable.

However, we don't actually want to rewrite partitions with all integer
loads and stores marked as splittable. This will fail to extract scalar
integers from aggregates, which is kind of the point of SROA. =] In
order to resolve this, what we really want to do is only do
pre-splitting on the alloca slices with integer loads and stores fully
splittable. This allows us to uncover all non-integer uses of the alloca
that would benefit from a split in an integer load or store (and where
introducing the split is safe because it is just memory transfer from
a load to a store). Once done, we make all the non-whole-alloca integer
loads and stores unsplittable just as they have historically been,
repartition and rewrite.

The result is that when there are integer loads and stores anywhere
within an alloca (such as from a memcpy of a sub-object of a larger
object), we can split them up if there are non-integer components to the
aggregate hiding beneath. I've added the challenging test cases to
demonstrate how this is able to promote to scalars even a case where we
have even *partially* overlapping loads and stores.

This restores the single-store behavior for small arrays of i8s which is
really nice. I've restored both the little endian testing and big endian
testing for these exactly as they were prior to r225061. It also forced
me to be more aggressive in an alignment test to actually defeat SROA.
=] Without the added volatiles there, we actually split up the weird i16
loads and produce nice double allocas with better alignment.

This also uncovered a number of bugs where we failed to handle
splittable load and store slices which didn't have a begininng offset of
zero. Those fixes are included, and without them the existing test cases
explode in glorious fireworks. =]

I've kept support for leaving whole-alloca integer loads and stores as
splittable even for the purpose of rewriting, but I think that's likely
no longer needed. With the new pre-splitting, we might be able to remove
all the splitting support for loads and stores from the rewriter. Not
doing that in this patch to try to isolate any performance regressions
that causes in an easy to find and revert chunk.

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

[SROA] Make the computation of adjusted pointers not leak GEP
instructions.

I noticed this when working on dialing up how aggressively we can
pre-split loads and stores. My test case wasn't passing because dead
GEPs into the allocas persisted when they were built by this routine.
This isn't terribly harmful, we still rewrote and promoted the alloca
and I can't conceive of how to cause this to happen in a case where we
will keep the exact same alloca but rewrite and promote the uses of it.
If that ever happened, we'd get an assert out of mem2reg.

So I don't have a direct test case yet, but the subsequent commit's test
case wouldn't pass without this. There are other problems fixed by this
patch that I spotted purely by inspection such as the fact that
getAdjustedPtr could have actually deleted dead base pointers. I don't
know how to get a base pointer to go into getAdjustedPtr today, so
I think this bug could never have manifested (and I certainly can't
write a test case for it) but, it wasn't the intent of the code. The
code really just wanted to GC the new instructions built. That can be
done more directly by comparing with the base pointer which is the only
non-new instruction that this code can return.

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

[SROA] Add a test case for r225068 / PR22080.

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

[SROA] Fix the loop exit placement to be prior to indexing the splits
array. This prevents it from walking out of bounds on the splits array.

Bug found with the existing tests by ASan and by the MSVC debug build.

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

[SROA] Fix two total think-os in r225061 that should have been caught on
a +asserts bootstrap, but my bootstrap had asserts off. Oops.

Anyways, in some places it is reasonable to cast (as a sanity check) the
pointer operand to a load or store to an instruction within SROA --
namely when the pointer operand is expected to be derived from an
alloca, and thus always an instruction. However, the pre-splitting code
also deals with loads and stores to non-alloca pointers and there we
need to just use the Value*. Nothing about the code relied on the
instruction cast, it was only there essentially as an invariant
assertion. Remove the two that don't actually hold.

This should fix the proximate issue in PR22080, but I'm also doing an
asserts bootstrap myself to see if there are other issues lurking.

I'll craft a reduced test case in a moment, but I wanted to get the tree
healthy as quickly as possible.

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

[PowerPC] use UINT64_C instead of ul

Attempting to fix PR22078 (building on 32-bit systems) by replacing my careless
use of 1ul to be a uint64_t constant with UINT64_C(1).

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

Revert "Just use a using directive in SmallMapVector instead of inheriting from MapVector itself."

This reverts commit r225059. I think MSVC 2012 has a problem with this. This is
an attempt to fix one of the MSVC 2012 bots.

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

Revert r225053: Add an ArrayRef upcasting constructor from ArrayRef<U*> -> ArrayRef<T*> where T is a base of U.

This appears to have broken at least the windows build bots due to
compile errors in the predicate that didn't simply supress the overload.
I'm not sure what the fix is, and the bots have been broken for a long
time now so I'm just reverting until Michael can figure out a fix.

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

[SROA] Switch to using a more direct debug logging technique in one part
of my new load and store splitting, and fix a bug where it logged
a totally irrelevant slice rather than the actual slice in question.

The logging here previously worked because we used to place new slices
onto the back of the core sequence, but that caused other problems.
I updated the actual code to store new slices in their own vector but
didn't update the logging. There isn't a good way to reuse the logging
any more, and frankly it wasn't needed. We can directly log this bit
more easily.

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

[SROA] Fix formatting with clang-format which I managed to fail to do
prior to committing r225061. Sorry for that.

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

[SROA] Teach SROA how to much more intelligently handle split loads and
stores.

When there are accesses to an entire alloca with an integer
load or store as well as accesses to small pieces of the alloca, SROA
splits up the large integer accesses. In order to do that, it uses bit
math to merge the small accesses into large integers. While this is
effective, it produces insane IR that can cause significant problems in
the rest of the optimizer:

- It can cause load and store mismatches with GVN on the non-alloca side
  where we end up loading an i64 (or some such) rather than loading
  specific elements that are stored.
- We can't always get rid of the integer bit math, which is why we can't
  always fix the loads and stores to work well with GVN.
- This is especially bad when we have operations that mix poorly with
  integer bit math such as floating point operations.
- It will block things like the vectorizer which might be able to handle
  the scalar stores that underly the aggregate.

At the same time, we can't just directly split up these loads and stores
in all cases. If there is actual integer arithmetic involved on the
values, then using integer bit math is actually the perfect lowering
because we can often combine it heavily with the surrounding math.

The solution this patch provides is to find places where SROA is
partitioning aggregates into small elements, and look for splittable
loads and stores that it can split all the way to some other adjacent
load and store. These are uniformly the cases where failing to split the
loads and stores hurts the optimizer that I have seen, and I've looked
extensively at the code produced both from more and less aggressive
approaches to this problem.

However, it is quite tricky to actually do this in SROA. We may have
loads and stores to the same alloca, or other complex patterns that are
hard to handle. This complexity leads to the somewhat subtle algorithm
implemented here. We have to do this entire process as a separate pass
over the partitioning of the alloca, and split up all of the loads prior
to splitting the stores so that we can handle safely the cases of
overlapping, including partially overlapping, loads and stores to the
same alloca. We also have to reconstitute the post-split slice
configuration so we can avoid iterating again over all the alloca uses
(the slow part of SROA). But we also have to ensure that when we split
up loads and stores to *other* allocas, we *do* re-iterate over them in
SROA to adapt to the more refined partitioning now required.

With this, I actually think we can fix a long-standing TODO in SROA
where I avoided splitting as many loads and stores as probably should be
splittable. This limitation historically mitigated the fallout of all
the bad things mentioned above. Now that we have more intelligent
handling, I plan to remove the FIXME and more aggressively mark integer
loads and stores as splittable. I'll do that in a follow-up patch to
help with bisecting any fallout.

The net result of this change should be more fine-grained and accurate
scalars being formed out of aggregates. At the very least, Clang now
generates perfect code for this high-level test case using
std::complex<float>:

  #include <complex>

  void g1(std::complex<float> &x, float a, float b) {
    x += std::complex<float>(a, b);
  }
  void g2(std::complex<float> &x, float a, float b) {
    x -= std::complex<float>(a, b);
  }

  void foo(const std::complex<float> &x, float a, float b,
           std::complex<float> &x1, std::complex<float> &x2) {
    std::complex<float> l1 = x;
    g1(l1, a, b);
    std::complex<float> l2 = x;
    g2(l2, a, b);
    x1 = l1;
    x2 = l2;
  }

This code isn't just hypothetical either. It was reduced out of the hot
inner loops of essentially every part of the Eigen math library when
using std::complex<float>. Those loops would consistently and
pervasively hop between the floating point unit and the integer unit due
to bit math extraction and insertion of floating point values that were
"stored" in a 64-bit integer register around the loop backedge.

So far, this change has passed a bootstrap and I have done some other
testing and so far, no issues. That doesn't mean there won't be though,
so I'll be prepared to help with any fallout. If you performance swings
in particular, please let me know. I'm very curious what all the impact
of this change will be. Stay tuned for the follow-up to also split more
integer loads and stores.

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

Just use a using directive in SmallMapVector instead of inheriting from MapVector itself.

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

[PowerPC] Improve instruction selection bit-permuting operations (64-bit)

This is the second installment of improvements to instruction selection for "bit
permutation" instruction sequences. r224318 added logic for instruction
selection for 32-bit bit permutation sequences, and this adds lowering for
64-bit sequences. The 64-bit sequences are more complicated than the 32-bit
ones because:
  a) the 64-bit versions of the 32-bit rotate-and-mask instructions
     work by replicating the lower 32-bits of the value-to-be-rotated into the
     upper 32 bits -- and integrating this into the cost modeling for the various
     bit group operations is non-trivial
  b) unlike the 32-bit instructions in 32-bit mode, the rotate-and-mask instructions
     cannot, in one instruction, specify the
     mask starting index, the mask ending index, and the rotation factor. Also,
     forming arbitrary 64-bit constants is more complicated than in 32-bit mode
     because the number of instructions necessary is value dependent.

Plus, support for 'late masking' was added: it is sometimes more efficient to
treat the overall value as if it had no mandatory zero bits when planning the
bit-group insertions, and then mask them in at the very end. Unfortunately, as
the structure of the bit groups is different in the two cases, the more
feasible implementation technique was to generate both instruction sequences,
and then pick the shorter one.

And finally, we now generate reasonable code for i64 bswap:

        rldicl 5, 3, 16, 0
        rldicl 4, 3, 8, 0
        rldicl 6, 3, 24, 0
        rldimi 4, 5, 8, 48
        rldicl 5, 3, 32, 0
        rldimi 4, 6, 16, 40
        rldicl 6, 3, 48, 0
        rldimi 4, 5, 24, 32
        rldicl 5, 3, 56, 0
        rldimi 4, 6, 40, 16
        rldimi 4, 5, 48, 8
        rldimi 4, 3, 56, 0

vs. what we used to produce:

        li 4, 255
        rldicl 5, 3, 24, 40
        rldicl 6, 3, 40, 24
        rldicl 7, 3, 56, 8
        sldi 8, 3, 8
        sldi 10, 3, 24
        sldi 12, 3, 40
        rldicl 0, 3, 8, 56
        sldi 9, 4, 32
        sldi 11, 4, 40
        sldi 4, 4, 48
        andi. 5, 5, 65280
        andis. 6, 6, 255
        andis. 7, 7, 65280
        sldi 3, 3, 56
        and 8, 8, 9
        and 4, 12, 4
        and 9, 10, 11
        or 6, 7, 6
        or 5, 5, 0
        or 3, 3, 4
        or 7, 9, 8
        or 4, 6, 5
        or 3, 3, 7
        or 3, 3, 4

which is 12 instructions, instead of 25, and seems optimal (at least in terms
of code size).

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

Add 2x constructors for TinyPtrVector, one that takes in one elemenet and the other that takes in an ArrayRef<EltTy>

Currently one can only construct an empty TinyPtrVector. These are just missing
elements of the API.

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

Add a SmallMapVector class that is a MapVector with a Map of SmallDenseMap and a Vector of SmallVector.

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

Add an ArrayRef upcasting constructor from ArrayRef<U*> -> ArrayRef<T*> where T is a base of U.

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

InstCombine: fsub nsz 0, X ==> fsub nsz -0.0, X

Some day the backend may handle instruction-level fast math flags and make
this transform unnecessary, but it's still better practice to use the canonical
representation of fneg when possible (use a -0.0).

This is a partial fix for PR20870 ( http://llvm.org/bugs/show_bug.cgi?id=20870 ).
See also http://reviews.llvm.org/D6723.

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

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

Add r224985 back with a fix.

The issues was that AArch64 has additional restrictions on when local
relocations can be used. We have to take those into consideration when
deciding to put a L symbol in the symbol table or not.

Original message:

Remove doesSectionRequireSymbols.

In an assembly expression like

bar:
.long L0 + 1

the intended semantics is that bar will contain a pointer one byte past L0.

In sections that are merged by content (strings, 4 byte constants, etc), a
single position in the section doesn't give the linker enough information.
For example, it would not be able to tell a relocation must point to the
end of a string, since that would look just like the start of the next.

The solution used in ELF to use relocation with symbols if there is a non-zero
addend.

In MachO before this patch we would just keep all symbols in some sections.

This would miss some cases (only cstrings on x86_64 were implemented) and was
inefficient since most relocations have an addend of 0 and can be represented
without the symbol.

This patch implements the non-zero addend logic for MachO too.

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

Reverting 225045 and 225043 and XFAIL multiline.ll on hexagon

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

Add a test for the recent compiler-rt build failure.

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

[Hexagon] Removing assertion to appease buildbot until I can reproduce the problem

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

Revert "Remove doesSectionRequireSymbols."

This reverts commit r224985.

I am investigating why it made an Apple bot unhappy.

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

[Hexagon] Changing an llvm_unreachable to an assertion and returning 0.  Relocations aren't implemented yet but we don't need to abort for this in release builds.

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

[X86] Update disassembler tests for absolute move instructions to check the encodings. This provides testing for r225036. 64-bit mode is still broken.

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

[X86] Fix disassembly of absolute moves to work correctly in 16 and 32-bit modes with all 4 combinations of OpSize and AdSize prefixes being present or not.

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

[x86] Simplify detection of jcxz/jecxz/jrcxz in disassembler.

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

InstCombine: try to transform A-B < 0 into A < B

We are allowed to move the 'B' to the right hand side if we an prove
there is no signed overflow and if the comparison itself is signed.

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

Revert "merge consecutive stores of extracted vector elements"

This reverts commit r224611. This change causes crashes
in X86 DAG->DAG Instruction Selection.

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

[Hexagon] Adding accumulating add/sub, doubleword logic-not variants, doubleword bitfield extract, word parity, accumulating multiplies with saturation.

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

Fix a test case to not depend on asm comment syntax, so as to be portable

Too many different comment characters - instead of trying to account for
them all, instead disable the comments and just check for end-of-line
instead.

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

Generalize even further, for ARM comment syntax (@)

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

[Hexagon] Adding double-logic on predicate instructions.

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

Generalize test case to handle different asm syntax (# or // comments)

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

[Hexagon] Adding newvalue compare and jumps.

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

RTDyldMemoryManager.cpp: Make the reference to __morestack weak.

This fixes the DSO build for now. Eventually we should develop some
other mechanism to make this work correctly with DSOs.

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

DebugInfo: Omit is_stmt from line table entries on the same line.

GCC does this for non-zero discriminators and since GCC doesn't produce
column info, that was the only place it comes up there. For LLVM, since
we can emit discriminators and/or column info, it makes more sense to
invert the condition and just test for changes in line number.

This should resolve at least some of the GDB 7.5 test suite failures
created by recent Clang changes that increase the location fidelity
(which, since Clang defaults to including column info on Linux by
default created a bunch of cases that confused GDB).

In theory we could do this better/differently by grouping actual source
statements together in a similar manner to the way lexical scopes are
handled but given that GDB isn't really in a position to consume that (&
users are probably somewhat used to different lines being different
'statements') this seems the safest and cheapest change. (I'm concerned
that doing this 'right' would bloat the debugloc data even further -
something Duncan's working hard to address)

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

[Hexagon] Adding postincrement register newvalue stores.

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

[Hexagon] Removing old newvalue store variants.  Adding postincrement immediate newvalue stores.

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

[mips][microMIPS] Relocate with symbol for micromips symbols
Differential Revision: http://reviews.llvm.org/D6796

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

[Hexagon] Adding indexed store new-value variants.

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

[Hexagon] Adding indexed store of immediates.

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

[Hexagon] Adding indexed stores.

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

x86_64: Fix calls to __morestack under the large code model.

Under the large code model, we cannot assume that __morestack lives within
2^31 bytes of the call site, so we cannot use pc-relative addressing. We
cannot perform the call via a temporary register, as the rax register may
be used to store the static chain, and all other suitable registers may be
either callee-save or used for parameter passing. We cannot use the stack
at this point either because __morestack manipulates the stack directly.

To avoid these issues, perform an indirect call via a read-only memory
location containing the address.

This solution is not perfect, as it assumes that the .rodata section
is laid out within 2^31 bytes of each function body, but this seems to
be sufficient for JIT.

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

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

[asan] change _sanitizer_cov_module_init to accept int* instead of int**

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

[COFF] Don't try to add quotes to already quoted linker directives

If a linker directive is already quoted, don't try to quote it again, otherwise it creates a mess.
This pops up in places like:
#pragma comment(linker,"\"/foo bar'\"")

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

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

[Hexagon] Adding reg-reg indexed load forms.

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

The __morestack function is only available on i386 and x86_64 architectures.

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

Make the __morestack function available to the JIT memory manager under Linux.

This function's implementation lives in libgcc, a static library, so we need
to expose it explicitly, like the other such functions.

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

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

[Hexagon] Dropping old combine instructions without encodings.

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

[Hexagon] Adding compare byte/halfword reg-reg/reg-imm forms.  Adding compare to general register reg-imm form.

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

[Hexagon] Updating constant extender def, adding alu-not instructions, compare to general register, and inverted compares.

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

Some code improvements in Masked Load/Store.
No functional changes.

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

Remove doesSectionRequireSymbols.

In an assembly expression like

bar:
.long L0 + 1

the intended semantics is that bar will contain a pointer one byte past L0.

In sections that are merged by content (strings, 4 byte constants, etc), a
single position in the section doesn't give the linker enough information.
For example, it would not be able to tell a relocation must point to the
end of a string, since that would look just like the start of the next.

The solution used in ELF to use relocation with symbols if there is a non-zero
addend.

In MachO before this patch we would just keep all symbols in some sections.

This would miss some cases (only cstrings on x86_64 were implemented) and was
inefficient since most relocations have an addend of 0 and can be represented
without the symbol.

This patch implements the non-zero addend logic for MachO too.

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

reverted prev commit (it was a mistake)

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

v

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

Add IRBuilder routines for gc.statepoints, gc.results, and gc.relocates

Nothing particularly interesting, just adding infrastructure for use by in tree users and out of tree users.

Note: These were extracted out of a working frontend, but they have not been well tested in isolation.

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

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

Simplify test a bit.

It looks like the original intent was to check which symbols were created.
With macho-dump the sections were being checked just to match which symbol
was in which section.

llvm-objdump prints the section a symbol is in.

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

[OCaml] Fix bitrot in tests.

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

[lit] Make config.llvm_lib_dir available on cmake, too.

The OCaml tests require config.llvm_lib_dir to determine
the OCaml package search path.

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

[OCaml] [cmake] Use LLVM_LIBRARY_DIR instead of LLVM_LIBRARY_OUTPUT_INTDIR.

The latter variable is internal.

Original patch by Ramkumar Ramachandra <artagnon@gmail.com>

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

Testcases for r224939.

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

Convert test to llvm-readobj. NFC.

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

Semantic tests for memory invalidation at statepoints

These are simply a collection of tests intended to show that information about the contents of gc references in the heap is lost at a statepoint. I've tried to write them so that they don't disallow correct transformations, while still being fairly easy to understand.

p.s. Ideas for additional tests are welcome.

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

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

Carry facts about nullness and undef across GC relocation

This change implements four basic optimizations:

    If a relocated value isn't used, it doesn't need to be relocated.
    If the value being relocated is null, relocation doesn't change that. (Technically, this might be collector specific. I don't know of one which it doesn't work for though.)
    If the value being relocated is undef, the relocation is meaningless.
    If the value being relocated was known nonnull, the relocated pointer also isn't null. (Since it points to the same source language object.)

I outlined other planned work in comments.

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

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

Refine the notion of MayThrow in LICM to include a header specific version

In LICM, we have a check for an instruction which is guaranteed to execute and thus can't introduce any new faults if moved to the preheader. To handle a function which might unconditionally throw when first called, we check for any potentially throwing call in the loop and give up.

This is unfortunate when the potentially throwing condition is down a rare path. It prevents essentially all LICM of potentially faulting instructions where the faulting condition is checked outside the loop. It also greatly diminishes the utility of loop unswitching since control dependent instructions - which are now likely in the loops header block - will not be lifted by subsequent LICM runs.

define void @nothrow_header(i64 %x, i64 %y, i1 %cond) {
; CHECK-LABEL: nothrow_header
; CHECK-LABEL: entry
; CHECK: %div = udiv i64 %x, %y
; CHECK-LABEL: loop
; CHECK: call void @use(i64 %div)
entry:
  br label %loop
loop: ; preds = %entry, %for.inc
  %div = udiv i64 %x, %y
  br i1 %cond, label %loop-if, label %exit
loop-if:
  call void @use(i64 %div)
  br label %loop
exit:
  ret void
}

The current patch really only helps with non-memory instructions (i.e. divs, etc..) since the maythrow call down the rare path will be considered to alias an otherwise hoistable load.  The one exception is that it does kick in for loads which are known to be invariant without regard to other possible stores, i.e. those marked with either !invarant.load metadata of tbaa 'is constant memory' metadata.

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

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

[go] Teach the go cmake build functions to funnel the include directories down into the cgo-setup variables of llvm-go.

Summary:
This in turn allows us to use #includes with cgo that rely on CMake
provided include directories which is particularly useful for handling
generated headers that aren't reasonable to put in an "installable"
location.

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

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

Loading from null is valid outside of addrspace 0

This patches fixes a miscompile where we were assuming that loading from null is undefined and thus we could assume it doesn't happen.  This transform is perfectly legal in address space 0, but is not neccessarily legal in other address spaces.

We really should introduce a hook to control this property on a per target per address space basis.  We may be loosing valuable optimizations in some address spaces by being too conservative.

Original patch by Thomas P Raoux (submitted to llvm-commits), tests and formatting fixes by me.

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

Convert test to llvm-readobj. NFC.

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

[Hexagon] Adding allocframe, post-increment circular immediate stores, post-increment circular register stores, and bit reversed post-increment stores.

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

[Hexagon] Fixing 224952 where an addressing mode update was missed.

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

Remove unnecessary StringRef->std::string conversion.

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

[Hexagon] Adding post-increment register form stores and register-immediate form stores with tests.

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

[Hexagon] Replacing the remaining postincrement stores with versions that have encoding bits.

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

Convert test to FileCheck. NFC.

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

[Hexagon] Renaming old multiclass for removal.  Adding post-increment store classes and instruction defs.

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

[py3] Teach the CMake build to reject Python versions older than 2.7.
Continue to require Python 2 however as recent experiments suggest
LLDB's build requires it.

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

[X86] Fix some cases where some 8-bit instructions were marked as being convertible to three address instructions, but aren't really.

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

[X86] Add the 0x82 instructions to the disassebmler. They are identical in functionality to the 0x80 opcode instructions, but are not valid in 64-bit mode.

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

[x86] Refactor some tablegen instruction info classes slightly to prepare for another change. NFC.

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

[x86] Remove unused classes from tablegen instruction info.

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

Add segmented stack support for DragonFlyBSD.

Patch by Michael Neumann.

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

Refactor duplicated code.

No intended functionality change.

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

[multilib] Add support to the autoconf build to substitute
a CLANG_LIBDIR_SUFFIX variable. This is necessary before I can add
support for using that variable to CMake and the C++ code in Clang, and
the autoconf build system does all substitutions in the LLVM tree.

As mentioned before, I'm not planning to add actual multilib support to
the autoconf build, just enough stubs for it to keep playing nicely with
the CMake build once that one has support.

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

[cmake] Teach the llvm-config program to respect LLVM_LIBDIR_SUFFIX.

For this to work, we have to encode it in the build variables and use it
from llvm-config.cpp. I've tried to do this reasonably cleanly, but the
code for llvm-config.cpp is pretty strange. However, with this,
llvm-config stops giving the wrong answer when using LLVM_LIBDIR_SUFFIX.

Note that the configure+make build just sets this to an empty string as
that build system has zero support for multilib of any form. I'm not
planning to add support there either, but this should leave a path for
anyone that wanted to.

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

[cmake] Push LLVM_LIBDIR_SUFFIX through to the LLVMConfig.cmake file
that is used by other projects to build against LLVM. This will allow
subsequent patches to them to use LLVM_LIBDIR_SUFFIX, both when built as
part of the larger LLVM build an as part of a standalone build against
an installed set of LLVM libraries.

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

[cmake] Start making LLVM_LIBDIR_SUFFIX effective by adding it to
*numerous* places where it was missing in the CMake build. The primary
change here is that the suffix is now actually used for all of the lib
directories in the LLVM project's CMake. The various subprojects still
need similar treatment.

This is the first of a series of commits to try to make LLVM's cmake
effective in a multilib Linux installation. I don't think many people
are seriously using this variable so I'm hoping the fallout will be
minimal. A somewhat unfortunate consequence of the nature of these
commits is that until I land all of them, they will in part make the
brokenness of our multilib support more apparant. At the end, things
should actually work.

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

Fixed 2 minor typos in the documentation.

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

llvm/test/CodeGen/X86/fast-isel-call-bool.ll: Add explicit -mtriple=x86_64-unknown to satisfy x64.

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

[X86][ISel] Fix a regression I introduced in r224884

The else case ResultReg was not checked for validity.
To my surprise, this case was not hit in any of the
existing test cases. This includes a new test cases
that tests this path.

Also drop the `target triple` declaration from the
original test as suggested by H.J. Lu, because
apparently with it the test won't be run on Linux

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

[X86] Add missing memory variants to AVX false dependency breaking

Adds missing memory instruction variants to AVX false dependency breaking handling. (SSE was handled in r224246)

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

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

[CodeGenPrepare] Teach when it is profitable to speculate calls to @llvm.cttz/ctlz.

If the control flow is modelling an if-statement where the only instruction in
the 'then' basic block (excluding the terminator) is a call to cttz/ctlz,
CodeGenPrepare can try to speculate the cttz/ctlz call and simplify the control
flow graph.

Example:
\code
entry:
  %cmp = icmp eq i64 %val, 0
  br i1 %cmp, label %end.bb, label %then.bb

then.bb:
  %c = tail call i64 @llvm.cttz.i64(i64 %val, i1 true)
  br label %end.bb

end.bb:
  %cond = phi i64 [ %c, %then.bb ], [ 64, %entry]
\code

In this example, basic block %then.bb is taken if value %val is not zero.
Also, the phi node in %end.bb would propagate the size-of in bits of %val
only if %val is equal to zero.

With this patch, CodeGenPrepare will try to hoist the call to cttz from %then.bb
into basic block %entry only if cttz is cheap to speculate for the target.

Added two new hooks in TargetLowering.h to let targets customize the behavior
(i.e. decide whether it is cheap or not to speculate calls to cttz/ctlz). The
two new methods are 'isCheapToSpeculateCtlz' and 'isCheapToSpeculateCttz'.
By default, both methods return 'false'.
On X86, method 'isCheapToSpeculateCtlz' returns true only if the target has
LZCNT. Method 'isCheapToSpeculateCttz' only returns true if the target has BMI.

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

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

Scalarizer for masked load and store intrinsics.

Masked vector intrinsics are a part of common LLVM IR, but they are really supported on AVX2 and AVX-512 targets. I added a code that translates masked intrinsic for all other targets. The masked vector intrinsic is converted to a chain of scalar operations inside conditional basic blocks.

http://reviews.llvm.org/D6436

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

[x86] Prevent instruction selection of AVX512 cmp.ps/pd/ss/sd intrinsics with illegal immediates. Correctly this time. I did the wrong patterns the first time.

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

PowerPC: CTR shouldn't fire if a TLS call is in the loop

Determining the address of a TLS variable results in a function call in
certain TLS models.  This means that a simple ICmpInst might actually
result in invalidating the CTR register.

In such cases, do not attempt to rely on the CTR register for loop
optimization purposes.

This fixes PR22034.

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

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

Fixing another -Wunused-variable warning, this time in release builds without asserts. NFC.

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

Removing a variable that is set but never used, to silence a -Wunused-but-set-variable warning; NFC.

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

[x86] Prevent instruction selection of AVX512 cmp.ps/pd/ss/sd intrinsics with illegal immediates. Forgot to do this when I did SSE/SSE2/AVX/AVX2.

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

[x86] Assert on invalid immediates in the instruction printer for cmp.ps/pd/ss/sd instead of truncating the immediate. The assembly parser and instruction selection shouldn't generate invalid immediates.

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

[x86] Prevent llvm.x86.cmp.ps/pd/ss/sd from being selected with bad immediates. The frontend now checks this when the builtin is used. This will allow the instruction printer to not have to deal with invalid immediates on these instructions.

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

[FastIsel][X86] Fix invalid register replacement for bool args

Summary:
Consider the following IR:

  %3 = load i8* undef
  %4 = trunc i8 %3 to i1
  %5 = call %jl_value_t.0* @foo(..., i1 %4, ...)
  ret %jl_value_t.0* %5

Bools (that are the result of direct truncs) are lowered as whatever
the argument to the trunc was and a "and 1", causing the part of the
MBB responsible for this argument to look something like this:

  %vreg8<def,tied1> = AND8ri %vreg7<kill,tied0>, 1, %EFLAGS<imp-def>; GR8:%vreg8,%vreg7

Later, when the load is lowered, it will insert

  %vreg15<def> = MOV8rm %vreg14, 1, %noreg, 0, %noreg; mem:LD1[undef] GR8:%vreg15 GR64:%vreg14

but remember to (at the end of isel) replace vreg7 by vreg15. Now for
the bug. In fast isel lowering, we mistakenly mark vreg8 as the result
of the load instead of the trunc. This adds a fixup to have
vreg8 replaced by whatever the result of the load is as well, so
we end up with

  %vreg15<def,tied1> = AND8ri %vreg15<kill,tied0>, 1, %EFLAGS<imp-def>; GR8:%vreg15

which is an SSA violation and causes problems later down the road.

This fixes PR21557.

Test Plan: Test test case from PR21557 is added to the test suite.

Reviewers: ributzka

Reviewed By: ributzka

Subscribers: llvm-commits

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

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