Add some convenience accessors for the underlying Use of an operand.
These complement many of the existing accessors and make it
significantly easier to write code which needs to poke at the underlying
Use without hard coding the operand number at which it resides for
a particular instruction. No functionality changed of course.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@202102 91177308-0d34-0410-b5e6-96231b3b80d8
[SROA] Use a more direct way of determining whether we are processing
the destination operand or source operand of a memmove.

It so happens that it was impossible for SROA to try to rewrite
self-memmove where the operands are *identical*, because either such
a think is volatile (and we don't rewrite) or it is non-volatile, and we
don't even register it as a use of the alloca.

However, making the 'IsDest' test *rely* on this subtle fact is... Very
confusing for the reader. We should use the direct and readily available
test of the Use* which gives us concrete information about which operand
is being rewritten.

No functionality changed, I hope! ;]

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@202103 91177308-0d34-0410-b5e6-96231b3b80d8
[SROA] Add a debugging tool which shuffles the slices sequence prior to
sorting it. This helps uncover latent reliance on the original ordering
which aren't guaranteed to be preserved by std::sort (but often are),
and which are based on the use-def chain orderings which also aren't
(technically) guaranteed.

Only available in C++11 debug builds, and behind a flag to prevent noise
at the moment, but this is generally useful so figured I'd put it in the
tree rather than keeping it out-of-tree.

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

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

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@202119 91177308-0d34-0410-b5e6-96231b3b80d8
Add aarch64 to config.guess

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@202125 91177308-0d34-0410-b5e6-96231b3b80d8
Ignore old JIT tests in AARch64 - CMake style

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@202126 91177308-0d34-0410-b5e6-96231b3b80d8
Disable old JIT unittests for AARch64

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@202127 91177308-0d34-0410-b5e6-96231b3b80d8
[SROA] Fix a *glaring* bug in r202091: you have to actually *write*
the break statement, not just think it to yourself....

No idea how this worked at all, much less survived most bots, my
bootstrap, and some bot bootstraps!

The Polly one didn't survive, and this was filed as PR18959. I don't
have a reduced test case and honestly I'm not seeing the need. What we
probably need here are better asserts / debug-build behavior in
SmallPtrSet so that this madness doesn't make it so far.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@202129 91177308-0d34-0410-b5e6-96231b3b80d8
Reuse constants for COFF string table entry offsets

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@202130 91177308-0d34-0410-b5e6-96231b3b80d8
[SROA] Adjust to new clang-format style.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@202134 91177308-0d34-0410-b5e6-96231b3b80d8
[SROA] Simplify some of the logic to dig out the old pointer value by
using OldPtr more heavily. Lots of this code was written before the
rewriter had an OldPtr member setup ahead of time. There are already
asserts in place that should ensure this doesn't change any
functionality.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@202135 91177308-0d34-0410-b5e6-96231b3b80d8
[SROA] Rather than copying the logic for building a name prefix into the
PHI-pointer builder, just copy the builder and clobber the obvious
fields.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@202136 91177308-0d34-0410-b5e6-96231b3b80d8
[SROA] Thread the ability to add a pointer-specific name prefix through
the pointer adjustment code. This is the primary code path that creates
totally new instructions in SROA and being able to lump them based on
the pointer value's name for which they were created causes
*significantly* fewer name collisions and general noise in the debug
output. This is particularly significant because it is making it much
harder to track down instability in the output of SROA, as name
de-duplication is a totally harmless form of instability that gets in
the way of seeing real problems.

The new fancy naming scheme tries to dig out the root "pre-SROA" name
for pointer values and associate that all the way through the pointer
formation instructions. Digging out the root is important to prevent the
multiple iterative rounds of SROA from just layering too much cruft on
top of cruft here. We already track the layers of SROAs iteration in the
alloca name prefix. We don't need to duplicate it here.

Should have no functionality change, and shouldn't have any really
measurable impact on NDEBUG builds, as most of the complex logic is
debug-only.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@202139 91177308-0d34-0410-b5e6-96231b3b80d8
[SROA] Use the original load name with the SROA-prefixed IRB rather than
just "load". This helps avoid pointless de-duping with order-sensitive
numbers as we already have unique names from the original load. It also
makes the resulting IR quite a bit easier to read.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@202140 91177308-0d34-0410-b5e6-96231b3b80d8
Make a few more DataLayout variables const.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@202155 91177308-0d34-0410-b5e6-96231b3b80d8
Factor out calls to AA.getDataLayout().

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@202157 91177308-0d34-0410-b5e6-96231b3b80d8
[XCore] Prefer to word align functions.

The behaviour of the XCore's instruction buffer means that the performance
of the same code sequence can differ depending on whether it starts at a 4
byte aligned address or not. Since we don't model the instruction buffer
in the backend we have no way of knowing for sure if it is beneficial to
word align a specific function. However, in the absence of precise
modelling, it is better on balance to word align functions because:

* It makes a fetch-nop while executing the prologue slightly less likely.
* If we don't word align functions then a small perturbation in one
  function can have a dramatic knock on effect. If the size of the function
  changes it might change the alignment and therefore the performance of
  all the functions that happen to follow it in the binary. This butterfly
  effect makes it harder to reason about and measure the performance of
  code.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@202163 91177308-0d34-0410-b5e6-96231b3b80d8
Keep the link register for uwtable.

The function with uwtable attribute might be visited by the
stack unwinder, thus the link register should be considered
as clobbered after the execution of the branch and link
instruction (i.e. the definition of the machine instruction
can't be ignored) even when the callee function are marked
with noreturn.


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@202165 91177308-0d34-0410-b5e6-96231b3b80d8
Make DataLayout a plain object, not a pass.

Instead, have a DataLayoutPass that holds one. This will allow parts of LLVM
don't don't handle passes to also use DataLayout.

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