llvm-svn: 198658

This is a follow up of the r198338 commit that added truncates for
lcssa phi nodes. Sinking the truncates below the phis cleans up the
loop and simplifies subsequent analysis within the indvars pass.

llvm-svn: 198654

llvm-svn: 198653

This patch adds .abicalls and .set pic0 support which
affects the ELF ABI and its flags. In addition the patch uses
a common interface for both the MipsTargetSteamer and
MipsObjectStreamer that both the integrated and standalone
assemblers will use for the output for these directives.

llvm-svn: 198646

SymbolLookUp() call back to return a demangled C++ name to
be used as a comment.

For example darwin's otool(1) program the uses the llvm
disassembler now can produce disassembly like:

callq   __ZNK4llvm6Target20createMCDisassemblerERKNS_15MCSubtargetInfoE ## llvm::Target::createMCDisassembler(llvm::MCSubtargetInfo const&) const

Also fix a bug in LLVMDisasmInstruction() that was not flushing
the raw_svector_ostream for the disassembled instruction string
before copying it to the output buffer that was causing truncation
of the output.

rdar://10173828

llvm-svn: 198637

llvm-svn: 198636

llvm-svn: 198632

Now with a fix for PR18384: ValueHandleBase::ValueIsDeleted.

We need to invalidate SCEV's loop info when we delete a block, even if no values are hoisted.

llvm-svn: 198631

Introduce a cmake LLVM_ENABLE_LIBCXX build parameter to compile using libc++ instead of the system default 

Summary:
This parameter is required to build C++11 projects (like lld or lldb) on OS X as the default STL does not provide c++ classes.


CC: llvm-commits, triton

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

llvm-svn: 198625

llvm-svn: 198624

The ARM backend has been using most of the MachO related subtarget
checks almost interchangeably, and since the only target it's had to
run on has been IOS (which is all three of MachO, Darwin and IOS) it's
worked out OK so far.

But we'd like to support embedded targets under the "*-*-none-macho"
triple, which means everything starts falling apart and inconsistent
behaviours emerge.

This patch should pick a reasonably sensible set of behaviours for the
new triple (and any others that come along, with luck). Some choices
were debatable (notably FP == r7 or r11), but we can revisit those
later when deficiencies become apparent.

llvm-svn: 198617

llvm-svn: 198616

llvm-svn: 198615

This requires a knowledge of the stack size which is not known until
the frame is complete, hence the need for the XCoreFTAOElim pass
which lowers the XCoreISD::FRAME_TO_ARGS_OFFSET instrution into its
final form.

llvm-svn: 198614

Only handles a depth of zero (the same as FRAMEADDR)

llvm-svn: 198613

llvm-svn: 198612

We also narrow the liveness of FP & LR during the prologue to
reflect the actual usage of the registers.
I have been unable to construct a test to prove the previous live
range was too large.

llvm-svn: 198611

This common functionality will be used to lower FRAME_TO_ARGS_OFFSET.

llvm-svn: 198610

llvm-svn: 198609

Longer term, we want to move users to "*-*-*-macho" for embedded work, but for
now people are relying on the last thing we told them, which is unfortunately
"*-*-darwin-eabi".

rdar://problem/15703934

llvm-svn: 198602

llvm-svn: 198593

llvm-svn: 198592

llvm-svn: 198591

Instead of crashing, raise an error when a subtraction expression
involves an undefined symbol.

This fixes PR18375.

llvm-svn: 198590

llvm-svn: 198589

llvm-svn: 198588

llvm-svn: 198587

The 0x66 prefix toggles between 16-bit and 32-bit addressing mode.
So in 32-bit mode it is used to switch to 16-bit addressing mode for the
following instruction, while in 16-bit mode it's the other way round — it's
used to switch to 32-bit mode instead.

Thus, emit the 0x66 prefix byte for OpSize only in 32-bit (and 64-bit) mode,
and introduce a new OpSize16 bit which is used in 16-bit mode instead.

This is just the basic infrastructure for that change; a subsequent patch
will add the new OpSize16 bit to the 32-bit instructions that need it.

Patch from David Woodhouse.

llvm-svn: 198586

llvm-svn: 198585

This is not really expected to work right yet. Mostly because we will
still emit the OpSize (0x66) prefix in all the wrong places, along with
a number of other corner cases. Those will all be fixed in the subsequent
commits.

Patch from David Woodhouse.

llvm-svn: 198584

Add a reference to the ARM EHABI Specification as a follow up to SVN r198576

llvm-svn: 198583

There is a wrong assumption that the vector element type and the
type of each ConstantSDNode in the build_vector were the same.
However, when promoting the integer operand of a legally typed
build_vector, the operand type and the vector element type do not
need to be the same
(See method 'DAGTypeLegalizer::PromoteIntOp_BUILD_VECTOR' in
LegalizeIntegerTypes.cpp).

  in AArch64 backend, the following dag sequence:

  C0: i1 = Constant<0>
  C1: i1 = Constant<-1>
  V: v8i1 = BUILD_VECTOR C1, C1, C0, C0, C0, C0, C0, C0

  is type-legalized into:

  NewC0: i32 = Constant<0>
  NewC1: i32 = Constant<1>
  V: v8i8 = BUILD_VECTOR NewC1, NewC1, NewC0, NewC0, NewC0, NewC0, NewC0, NewC0

Forcing a getZeroExtend to VTBits to ensure that the new constant
is correctly.

llvm-svn: 198582

llvm-svn: 198580

This moves the check up into the parent class so that all targets can use it
without having to copy (and keep in sync) the same error message.

llvm-svn: 198579

llvm-svn: 198578

llvm-svn: 198577

Move the ARM EHABI unwind opcode definitions from the ARM MCTargetDesc into LLVM
Support.  This enables sharing of the definitions across the ARM target code as
well as llvm-readobj.  This will allow implementation of the unwind decoding in
llvm-readobj.

llvm-svn: 198576

llvm-svn: 198567

Add some tests to validate correct register selection, including a fix
to an existing test which was requiring the *wrong* output.

Patch from David Woodhouse.

llvm-svn: 198566

llvm-svn: 198565