Use m_OneUse pattern instead of hasOneUse() method.
No functionality change.


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@169703 91177308-0d34-0410-b5e6-96231b3b80d8
So many people have touched this, it doesn't make sense to ascribe authorship anymore.


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


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@169709 91177308-0d34-0410-b5e6-96231b3b80d8
Have the bitcode reader/writer just use FPMathOperator's fast math enum directly

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@169710 91177308-0d34-0410-b5e6-96231b3b80d8
LoopVectorize: support vectorizing intrinsic calls

- added function to VectorTargetTransformInfo to query cost of intrinsics
- vectorize trivially vectorizable intrinsic calls such as sin, cos, log, etc.

Reviewed by: Nadav


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@169711 91177308-0d34-0410-b5e6-96231b3b80d8
Reorganize FastMathFlags to be a wrapper around unsigned, and streamline some interfaces.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@169712 91177308-0d34-0410-b5e6-96231b3b80d8
Documentation: convert ReleaseNotes.html to reST.

Patch by Anthony Mykhailenko with small fixes by me.


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@169714 91177308-0d34-0410-b5e6-96231b3b80d8
Fix PR14548: SROA was crashing on a mixture of i1 and i8 loads and stores.

When SROA was evaluating a mixture of i1 and i8 loads and stores, in
just a particular case, it would tickle a latent bug where we compared
bits to bytes rather than bits to bits. As a consequence of the latent
bug, we would allow integers through which were not byte-size multiples,
a situation the later rewriting code was never intended to handle.

In release builds this could trigger all manner of oddities, but the
reported issue in PR14548 was forming invalid bitcast instructions.

The only downside of this fix is that it makes it more clear that SROA
in its current form is not capable of handling mixed i1 and i8 loads and
stores. Sometimes with the previous code this would work by luck, but
usually it would crash, so I'm not terribly worried. I'll watch the LNT
numbers just to be sure.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@169719 91177308-0d34-0410-b5e6-96231b3b80d8
Revert to old behavior until linker can pass export-dynamic option.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@169720 91177308-0d34-0410-b5e6-96231b3b80d8
[CMake] Update dependencies to intrinsics_gen corresponding to r169711.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@169724 91177308-0d34-0410-b5e6-96231b3b80d8
[CMake] TARGET_TRIPLE may be internal alias of LLVM_DEFAULT_TARGET_TRIPLE.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@169726 91177308-0d34-0410-b5e6-96231b3b80d8
Teach DAG combine to handle vector add/sub with vectors of all 0s.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@169727 91177308-0d34-0410-b5e6-96231b3b80d8
Add a new visitor for walking the uses of a pointer value.

This visitor provides infrastructure for recursively traversing the
use-graph of a pointer-producing instruction like an alloca or a malloc.
It maintains a worklist of uses to visit, so it can handle very deep
recursions. It automatically looks through instructions which simply
translate one pointer to another (bitcasts and GEPs). It tracks the
offset relative to the original pointer as long as that offset remains
constant and exposes it during the visit as an APInt offset. Finally, it
performs conservative escape analysis.

However, currently it has some limitations that should be addressed
going forward:
1) It doesn't handle vectors of pointers.
2) It doesn't provide a cheaper visitor when the constant offset
   tracking isn't needed.
3) It doesn't support non-instruction pointer values.

The current functionality is exactly what is required to implement the
SROA pointer-use visitors in terms of this one, rather than in terms of
their own ad-hoc base visitor, which was always very poorly specified.
SROA has been converted to use this, and the code there deleted which
this utility now provides.

Technically speaking, using this new visitor allows SROA to handle a few
more cases than it previously did. It is now more aggressive in ignoring
chains of instructions which look like they would defeat SROA, but in
fact do not because they never result in a read or write of memory.
While this is "neat", it shouldn't be interesting for real programs as
any such chains should have been removed by others passes long before we
get to SROA. As a consequence, I've not added any tests for these
features -- it shouldn't be part of SROA's contract to perform such
heroics.

The goal is to extend the functionality of this visitor going forward,
and re-use it from passes like ASan that can benefit from doing
a detailed walk of the uses of a pointer.

Thanks to Ben Kramer for the code review rounds and lots of help
reviewing and debugging this patch.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@169728 91177308-0d34-0410-b5e6-96231b3b80d8
Address a FIXME and update the fast unaligned memory feature for newer
Intel chips.

The model number rules were determined by inspecting Intel's
documentation for their newer chip model numbers. My understanding is
that all of the newer Intel chips have fast unaligned memory access, but
if anyone is concerned about a particular chip, just shout.

No tests updated; it's not clear we have dedicated tests for the chips'
various features, but if anyone would like tests (or can point me at
some existing ones), I'm happy to oblige.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@169730 91177308-0d34-0410-b5e6-96231b3b80d8
Fix a typo in my previous commit -- bloomfield is 0x1A not 0x2A.

Thanks to the PaX folks for noticing in review! We need some tests here,
any sugestions welcome...

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@169739 91177308-0d34-0410-b5e6-96231b3b80d8
Make '-mtune=x86_64' assume fast unaligned memory accesses.

Summary:
Not all chips targeted by x86_64 have this feature, but a dramatically
increasing number do. Specifying a chip-specific tuning parameter will
continue to turn the feature on or off as appropriate for that
particular chip, but the generic flag should try to achieve the best
performance on the most widely available hardware. Today, the number of
chips with fast UA access dwarfs those without in the x86-64 space.

Note that this also brings LLVM's code generation for this '-march' flag
more in line with that of modern GCCs.

CC: llvm-commits

Differential Revision: http://llvm-reviews.chandlerc.com/D195

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@169740 91177308-0d34-0410-b5e6-96231b3b80d8
Revert "Make '-mtune=x86_64' assume fast unaligned memory accesses."

Accidental commit... git svn betrayed me. Sorry for the noise.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@169741 91177308-0d34-0410-b5e6-96231b3b80d8
Fix funky copy-pasted grammatical error.

PR14343

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@169742 91177308-0d34-0410-b5e6-96231b3b80d8
Use GetUnderlyingObjects in misched

misched used GetUnderlyingObject in order to break false load/store
dependencies, and the -enable-aa-sched-mi feature similarly relied on
GetUnderlyingObject in order to ensure it is safe to use the aliasing analysis.
Unfortunately, GetUnderlyingObject does not recurse through phi nodes, and so
(especially due to LSR) all of these mechanisms failed for
induction-variable-dependent loads and stores inside loops.

This change replaces uses of GetUnderlyingObject with GetUnderlyingObjects
(which will recurse through phi and select instructions) in misched.

Andy reviewed, tested and simplified this patch; Thanks!

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@169744 91177308-0d34-0410-b5e6-96231b3b80d8
This patch adds statistics for other non-DWARF fragments emitted by
the assembler. This is useful in order to know how the numbers add up,
since in particular the Align fragments account for a non-trivial
portion of the emitted fragments (especially on -O0 which sets
relax-all).


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