llvm-svn: 155840

llvm-svn: 155832

On x86-32, structure return via sret lets the callee pop the hidden
pointer argument off the stack, which the caller then re-pushes.
However if the calling convention is fastcc, then a register is used
instead, and the caller should not adjust the stack. This is
implemented with a check of IsTailCallConvention
X86TargetLowering::LowerCall but is now checked properly in
X86FastISel::DoSelectCall.

(this time, actually commit what was reviewed!)

llvm-svn: 155825

ARM BUILD_VECTORs created after type legalization cannot use i8 or i16
operands, since those types are not legal.  Instead use i32 operands, which
will be implicitly truncated by the BUILD_VECTOR to match the element type.

llvm-svn: 155824

relocations are resolved.  It's much more reasonable to do this decision when
relocations are just being added - we have all the information at that point.

Also a bit of renaming and extra comments to clarify extensions.

llvm-svn: 155819

known zero in the LHS.  Fixes PR12541.

llvm-svn: 155818

Allow the "SplitCriticalEdge" function to split the edge to a landing pad. If
the pass is *sure* that it thinks it knows what it's doing, then it may go ahead
and specify that the landing pad can have its critical edge split. The loop
unswitch pass is one of these passes. It will split the critical edges of all
edges coming from a loop to a landing pad not within the loop. Doing so will
retain important loop analysis information, such as loop simplify.

llvm-svn: 155817

llvm-svn: 155816

- Add comments
- Change field names to be more reasonable
- Fix indentation and naming to conform to coding conventions
- Remove unnecessary includes / replace them by forward declatations

llvm-svn: 155815

llvm-svn: 155813

llvm-svn: 155811

Copied all the VEX prefix encoding code from X86MCCodeEmitter to the x86 JIT emitter.  Needs some major refactoring as these two code emitters are almost identical

llvm-svn: 155810

inputs.

llvm-svn: 155809

llvm-svn: 155800

llvm-svn: 155799

llvm-svn: 155798

llvm-svn: 155797

llvm-svn: 155795

llvm-svn: 155793

if !ForceInterpreteri). It has no effect (apart from a memory leak...)

llvm-svn: 155792

llvm-svn: 155791

llvm-svn: 155790

llvm-svn: 155787

llvm-svn: 155786

Mark the default cases of MVT::getVectorElementType and MVT:getVectorNumElements as unreachable to reduce code size.

llvm-svn: 155785

We don't compute spill weights until after coalescing anyway.

llvm-svn: 155766

llvm-svn: 155765

This way we can enable the POD-like class optimization for a lot more classes,
saving ~120k of code in clang/i386/Release+Asserts when selfhosting.

llvm-svn: 155761

llvm-svn: 155760

The code could search past the end of the basic block when there was
already a constant pool entry after the block.

Test case with giant basic block in SingleSource/UnitTests/Vector/constpool.c

llvm-svn: 155753

This time, also fix the caller of AddGlue to properly handle
incomplete chains. AddGlue had failure modes, but shamefully hid them
from its caller. It's luck ran out.

Fixes rdar://11314175: BuildSchedUnits assert.

llvm-svn: 155749

Make sure when parsing the Thumb1 sp+register ADD instruction that
the source and destination operands match. In thumb2, just use the
wide encoding if they don't. In Thumb1, issue a diagnostic.

rdar://11219154

llvm-svn: 155748

Make the operand order of the instruction match that of the asm syntax.

llvm-svn: 155747

llvm-svn: 155746

On x86-32, structure return via sret lets the callee pop the hidden
pointer argument off the stack, which the caller then re-pushes.
However if the calling convention is fastcc, then a register is used
instead, and the caller should not adjust the stack. This is
implemented with a check of IsTailCallConvention
X86TargetLowering::LowerCall but is now checked properly in
X86FastISel::DoSelectCall.

llvm-svn: 155745

Previously, ARMConstantIslandPass would conservatively compute the
address of an aligned basic block as:

  RoundUpToAlignment(Offset + UnknownPadding)

This worked fine for the layout algorithm itself, but it could fool the
verify() function because it accounts for alignment padding twice: Once
when adding the worst case UnknownPadding, and again by rounding up the
fictional block offset. This meant that when optimizeThumb2Instructions
would shrink an instruction, the conservative distance estimate could
grow. That shouldn't be possible since the woorst case alignment padding
wss already included.

This patch drops the use of RoundUpToAlignment, and depends only on
worst case padding to compute conservative block offsets. This has the
weird effect that the computed offset for an aligned block may not be
aligned.

The important difference is that shrinking an instruction can never
cause the estimated distance between two instructions to grow. The
estimated distance is always larger than the real distance that only the
assembler knows.

<rdar://problem/11339352>

llvm-svn: 155744

This definitely caused regression with ARM -mno-thumb.

llvm-svn: 155743

llvm-svn: 155742

 x == -y --> x+y == 0
 x != -y --> x+y != 0

On x86, the generated code goes from
   negl    %esi
   cmpl    %esi, %edi
   je    .LBB0_2
to
   addl    %esi, %edi
   je    .L4

This case is correctly handled for ARM with "cmn".

Patch by Manman Ren.
rdar://11245199
PR12545

llvm-svn: 155739

llvm-svn: 155735