[PowerPC] Remove symbolLo/symbolHi instruction operand types

Now that there is no longer any distinction between symbolLo
and symbolHi operands in either printing, encoding, or parsing,
the operand types can be removed in favor of simply using
s16imm.

This completes the patch series to decouple lo/hi operand part
processing from the particular instruction whose operand it is.

No change in code generation expected from this patch.



git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@182618 91177308-0d34-0410-b5e6-96231b3b80d8
Add MCSymbolizer for symbolic/annotated disassembly.

This is a basic first step towards symbolization of disassembled
instructions. This used to be done using externally provided (C API)
callbacks. This patch introduces:
- the MCSymbolizer class, that mimics the same functions that were used
  in the X86 and ARM disassemblers to symbolize immediate operands and
  to annotate loads based off PC (for things like c string literals).
- the MCExternalSymbolizer class, which implements the old C API.
- the MCRelocationInfo class, which provides a way for targets to
  translate relocations (either object::RelocationRef, or disassembler
  C API VariantKinds) to MCExprs.
- the MCObjectSymbolizer class, which does symbolization using what it
  finds in an object::ObjectFile. This makes simple symbolization (with
  no fancy relocation stuff) work for all object formats!
- x86-64 Mach-O and ELF MCRelocationInfos.
- A basic ARM Mach-O MCRelocationInfo, that provides just enough to
  support the C API VariantKinds.

Most of what works in otool (the only user of the old symbolization API
that I know of) for x86-64 symbolic disassembly (-tvV) works, namely:
- symbol references: call _foo; jmp 15 <_foo+50>
- relocations:       call _foo-_bar; call _foo-4
- __cf?string:       leaq 193(%rip), %rax ## literal pool for "hello"
Stub support is the main missing part (because libObject doesn't know,
among other things, about mach-o indirect symbols).

As for the MCSymbolizer API, instead of relying on the disassemblers
to call the tryAdding* methods, maybe this could be done automagically
using InstrInfo? For instance, even though PC-relative LEAs are used
to get the address of string literals in a typical Mach-O file, a MOV
would be used in an ELF file. And right now, the explicit symbolization
only recognizes PC-relative LEAs. InstrInfo should have already have
most of what is needed to know what to symbolize, so this can
definitely be improved.

I'd also like to remove object::RelocationRef::getValueString (it seems
only used by relocation printing in objdump), as simply printing the
created MCExpr is definitely enough (and cleaner than string concats).



git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@182625 91177308-0d34-0410-b5e6-96231b3b80d8
MC: Disassembled CFG reconstruction.

This patch builds on some existing code to do CFG reconstruction from
a disassembled binary:
- MCModule represents the binary, and has a list of MCAtoms.
- MCAtom represents either disassembled instructions (MCTextAtom), or
  contiguous data (MCDataAtom), and covers a specific range of addresses.
- MCBasicBlock and MCFunction form the reconstructed CFG. An MCBB is
  backed by an MCTextAtom, and has the usual successors/predecessors.
- MCObjectDisassembler creates a module from an ObjectFile using a
  disassembler. It first builds an atom for each section. It can also
  construct the CFG, and this splits the text atoms into basic blocks.

MCModule and MCAtom were only sketched out; MCFunction and MCBB were
implemented under the experimental "-cfg" llvm-objdump -macho option.
This cleans them up for further use; llvm-objdump -d -cfg now generates
graphviz files for each function found in the binary.

In the future, MCObjectDisassembler may be the right place to do
"intelligent" disassembly: for example, handling constant islands is just
a matter of splitting the atom, using information that may be available
in the ObjectFile. Also, better initial atom formation than just using
sections is possible using symbols (and things like Mach-O's
function_starts load command).

This brings two minor regressions in llvm-objdump -macho -cfg:
- The printing of a relocation's referenced symbol.
- An annotation on loop BBs, i.e., which are their own successor.

Relocation printing is replaced by the MCSymbolizer; the basic CFG
annotation will be superseded by more related functionality.



git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@182628 91177308-0d34-0410-b5e6-96231b3b80d8
Fix unused warning in opt builds.

In these builds, the asserts() are completely compiled out of the code
leaving "End" unused. Directly accessing it, should not have a
performance impact, as it is just a data member.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@182634 91177308-0d34-0410-b5e6-96231b3b80d8
Remove the Copied parameter from MemoryObject::readBytes.

There was exactly one caller using this API right, the others were relying on
specific behavior of the default implementation. Since it's too hard to use it
right just remove it and standardize on the default behavior.

Defines away PR16132.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@182636 91177308-0d34-0410-b5e6-96231b3b80d8
Add a new function attribute 'cold' to functions.

Other than recognizing the attribute, the patch does little else.
It changes the branch probability analyzer so that edges into
blocks postdominated by a cold function are given low weight.

Added analysis and code generation tests.  Added documentation for the
new attribute.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@182638 91177308-0d34-0410-b5e6-96231b3b80d8
scalarizePHI needs to insert the next ExtractElement in the same block
as the BinaryOperator, *not* in the block where the IRBuilder is currently
inserting into. Fixes a bug where scalarizePHI would create instructions
that would not dominate all uses.


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@182639 91177308-0d34-0410-b5e6-96231b3b80d8
Run clang-format over the scalarizePHI function.


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@182640 91177308-0d34-0410-b5e6-96231b3b80d8
[SystemZ] Improve AsmParser register parsing

The idea is to make sure that:

(1) "register expected" is restricted to cases where ParseRegister()
    is called and the token obviously isn't a register.

(2) "invalid register" is restricted to cases where a register-like "%..."
    sequence is found, but the "..." makes no sense.

(3) the generic "invalid operand for instruction" is used in cases where
    the wrong register type is used (GPR instead of FPR, etc.).

(4) the new "invalid register pair" is used if the register has the right type,
    but is not a valid register pair.

Testing of (1)-(3) is now restricted to regs-bad.s.  It uses a representative
instruction for each register class to make sure that only registers from
that class are accepted.

(4) is tested by both regs-bad.s (which checks all invalid register pairs)
and insn-bad.s (which tests one invalid pair for each instruction that
requires a pair).

While there, I changed "Number" to "Num" for consistency with the
operand class.


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@182643 91177308-0d34-0410-b5e6-96231b3b80d8
[SystemZ] Improve AsmParser handling of invalid instructions

Previously, an invalid instruction like:

	foo     %r1, %r0

would generate the rather odd error message:

....: error: unknown token in expression
	foo     %r1, %r0
		^

We now get the more informative:

....: error: invalid instruction
	foo     %r1, %r0
	^

The same would happen if an address were used where a register was expected.
We now get "invalid operand for instruction" instead.


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@182644 91177308-0d34-0410-b5e6-96231b3b80d8
Do not reserve space for the ColdEdges and NormalEdges vectors.
Discussion and rationale at
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20130520/175698.html

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@182653 91177308-0d34-0410-b5e6-96231b3b80d8
LoopVectorize: LoopSimplify can't canonicalize loops with an indirectbr in it, don't assert on those cases.

Fixes PR16139.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@182656 91177308-0d34-0410-b5e6-96231b3b80d8
[Support] Add type generic bit utilities to MathExtras.h

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@182667 91177308-0d34-0410-b5e6-96231b3b80d8
[objc-arc] Make sure that multiple owners is propogated correctly through the pass via the usage of a global data structure.

rdar://13750319

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@182669 91177308-0d34-0410-b5e6-96231b3b80d8
[objc-arc] KnownSafe does not imply that it is safe to perform code motion across CFG edges since even if it is safe to remove RR pairs, we may still be able to move a retain/release into a loop.

rdar://13949644

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@182670 91177308-0d34-0410-b5e6-96231b3b80d8
[Support][MathExtras] Add missing include and disable _BitScan{Forward,Reverse}64 on non x64 MSVC systems.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@182671 91177308-0d34-0410-b5e6-96231b3b80d8
Add missing header for atexit.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@182672 91177308-0d34-0410-b5e6-96231b3b80d8
[Support][MathExtras] Fix literal type issues.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@182679 91177308-0d34-0410-b5e6-96231b3b80d8
Replace Count{Leading,Trailing}Zeros_{32,64} with count{Leading,Trailing}Zeros.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@182680 91177308-0d34-0410-b5e6-96231b3b80d8
MathExtras: Return the result of find(First|Last)Set in the input type.

Otherwise ZB_Max returns a wrong result when sizeof(T) > sizeof(size_t).

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