[llvm-objdump] support -rebase option for mach-o to dump rebasing info

Similar to my previous -exports-trie option, the -rebase option dumps info from
the LC_DYLD_INFO load command. The rebasing info is a list of the the locations
that dyld needs to adjust if a mach-o image is not loaded at its preferred 
address. Since ASLR is now the default, images almost never load at their
preferred address, and thus need to be rebased by dyld.



git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@217709 91177308-0d34-0410-b5e6-96231b3b80d8
Allow targets to custom legalize vector insertion and extraction.


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@217711 91177308-0d34-0410-b5e6-96231b3b80d8
[AArch64] Don't enable the post-RA MI scheduler at OptNone.

Hopefully, this will appease the bots.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@217712 91177308-0d34-0410-b5e6-96231b3b80d8
Stop suppress error messages in test case to see why one buildbot is failing

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@217715 91177308-0d34-0410-b5e6-96231b3b80d8
[llvm-objdump] Use PRIX64 with format()

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@217724 91177308-0d34-0410-b5e6-96231b3b80d8
[AArch64] Update test case to pass with post-RA MI scheduler.

Check that the post RA scheduler is being skipped, regardless of
whether it's the top-down list latency scheduler or the post-RA
MI scheduler.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@217725 91177308-0d34-0410-b5e6-96231b3b80d8
Simplify code. No functionality change.

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

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@217730 91177308-0d34-0410-b5e6-96231b3b80d8
Add control of function merging to the PMBuilder.


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@217731 91177308-0d34-0410-b5e6-96231b3b80d8
[FastISel][AArch64] Add support for non-native types for logical ops.

Extend the logical ops selection to also support non-native types such as i1,
i8, and i16.

Fixes rdar://problem/18330589.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@217732 91177308-0d34-0410-b5e6-96231b3b80d8
[A57FPLoadBalancing] Modify r217689 - actually we do need to check defs

... Just make sure we check uses first so we see the kill first. It
turns out ignoring defs gives some pretty nasty runtime failures.
I'm certain this is the fix but I'm still reducing a testcase.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@217735 91177308-0d34-0410-b5e6-96231b3b80d8
R600/SI: Fix broken check lines

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@217736 91177308-0d34-0410-b5e6-96231b3b80d8
In DwarfEHPrepare, after all passes are run, RewindFunction may be a dangling
pointer to a dead function. To make sure it's valid, doFinalization nullptrs
RewindFunction just like the constructor and so it will be found on next run.



git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@217737 91177308-0d34-0410-b5e6-96231b3b80d8
[x86] Teach the vector combiner that picks a canonical shuffle from to
support transforming the forms from the new vector shuffle lowering to
use 'movddup' when appropriate.

A bunch of the cases where we actually form 'movddup' don't actually
show up in the test results because something even later than DAG
legalization maps them back to 'unpcklpd'. If this shows back up as
a performance problem, I'll probably chase it down, but it is at least
an encoded size loss. =/

To make this work, also always do this canonicalizing step for floating
point vectors where the baseline shuffle instructions don't provide any
free copies of their inputs. This also causes us to canonicalize
unpck[hl]pd into mov{hl,lh}ps (resp.) which is a nice encoding space
win.

There is one test which is "regressed" by this: extractelement-load.
There, the test case where the optimization it is testing *fails*, the
exact instruction pattern which results is slightly different. This
should probably be fixed by having the appropriate extract formed
earlier in the DAG, but that would defeat the purpose of the test.... If
this test case is critically important for anyone, please let me know
and I'll try to work on it. The prior behavior was actually contrary to
the comment in the test case and seems likely to have been an accident.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@217738 91177308-0d34-0410-b5e6-96231b3b80d8
[x86] Add some test cases where we should emit blendpd in SSE4.1. No
actual change yet though.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@217739 91177308-0d34-0410-b5e6-96231b3b80d8
[x86] Switch this test to use an ALL prefix with special SSE2 and SSE3
variants where significant.

This will make it more obvious what is happening when we start using
blends in SSE41.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@217740 91177308-0d34-0410-b5e6-96231b3b80d8
[x86] Add an SSE41 mode to this test. Nothing interesting here, its the
same as SSE3.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@217741 91177308-0d34-0410-b5e6-96231b3b80d8
llvm/test/CodeGen/X86/vec_shuffle-38.ll: Add explicit -mtriple=x86_64-unknown to avoid incompatibility of win32.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@217742 91177308-0d34-0410-b5e6-96231b3b80d8
[x86] Teach the new vector shuffle lowering to use BLENDPS and BLENDPD.

These are super simple. They even take precedence over crazy
instructions like INSERTPS because they have very high throughput on
modern x86 chips.

I still have to teach the integer shuffle variants about this to avoid
so many domain crossings. However, due to the particular instructions
available, that's a touch more complex and so a separate patch.

Also, the backend doesn't seem to realize it can commute blend
instructions by negating the mask. That would help remove a number of
copies here. Suggestions on how to do this welcome, it's an area I'm
less familiar with.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@217744 91177308-0d34-0410-b5e6-96231b3b80d8
llvm-cov: Simplify CounterMappingRegion, pushing logic to its user

A single function in SourceCoverageDataManager was the only user of
some of the comparisons in CounterMappingRegion, and at this point we
know that only one file is relevant. This lets us use slightly simpler
logic directly in the client.

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