rdar://10528060

llvm-svn: 145891

Previously, all ARM::CONSTPOOL_ENTRY instructions had a hardwired
alignment of 4 bytes emitted by ARMAsmPrinter.  Now the same alignment
is set on the basic block.

This is in preparation of supporting ARM constant pool islands with
different alignments.

llvm-svn: 145890

This was actually a bit of a mess. TLI.setPrefLoopAlignment was clearly
documented as taking log2(bytes) units, but the x86 target would still
set a preferred loop alignment of '16'.

CodePlacementOpt passed this number on to the basic block, and
AsmPrinter interpreted it as bytes.

Now both MachineFunction and MachineBasicBlock use logarithmic
alignments.

Obviously, MachineConstantPool still measures alignments in bytes, so we
can emulate the thrill of using as.

llvm-svn: 145889

value over that much.

llvm-svn: 145888

rdar://10069056

llvm-svn: 145885

llvm-svn: 145883

Whether a fixup needs relaxation for the associated instruction is a
target-specific function, as the FIXME indicated. Create a hook for that
and use it.

llvm-svn: 145881

Not right yet, as the rules for when to relax in the MCAssembler aren't
(yet) correct for ARM. This is a step in the proper direction, though.

llvm-svn: 145871

llvm-svn: 145863

rdar://10529664

llvm-svn: 145860

PerformANDCombine and PerformOrCombine aware of them. Test cases are included
too.

llvm-svn: 145853

them.

llvm-svn: 145852

rdar://10529348

llvm-svn: 145851

O32 with relocation-model=pic too.

llvm-svn: 145850

Finish up rdar://10522016.

llvm-svn: 145846

llvm-svn: 145844

llvm-svn: 145843

Combined destination and first source operand for f32 variant of the VMUL
(by scalar) instruction.

rdar://10522016

llvm-svn: 145842

llvm-svn: 145819

llvm-svn: 145818

llvm-svn: 145816

llvm-svn: 145804

llvm-svn: 145803

llvm-svn: 145783

Maybe some targets should use this as well.

Patch by Evgeniy Stepanov!

llvm-svn: 145781

AnalyzeBranch doesn't change the successor, just the order.

llvm-svn: 145779

libgcc sets the stack limit field in TCB to 256 bytes above the actual
allocated stack limit.  This means if the function's stack frame needs
less than 256 bytes, we can just compare the stack pointer with the
stack limit.  This should result in lesser calls to __morestack.

llvm-svn: 145766

Currently LLVM pads the call to __morestack with a add and sub of 8
bytes to esp.  This isn't correct since __morestack expects the call
to be followed directly by a ret.

This commit also adjusts the relevant test-case.

llvm-svn: 145765

the same value) to this variable. This code could be refactored, but it doesn't
matter since the old JIT is going away. Add tsan annotations to ignore the
race.

llvm-svn: 145745

rdar://10510150

llvm-svn: 145742

llvm-svn: 145726

llvm-svn: 145722

llvm-svn: 145718

change, now you need a TargetOptions object to create a TargetMachine. Clang
patch to follow.

One small functionality change in PTX. PTX had commented out the machine
verifier parts in their copy of printAndVerify. That now calls the version in
LLVMTargetMachine. Users of PTX who need verification disabled should rely on
not passing the command-line flag to enable it.

llvm-svn: 145714

llvm-svn: 145712

llvm-svn: 145711

argument value type.  Otherwise, the sign/zero-extend has no effect on arguments
passed via the stack (i.e., undefined high-order bits).
rdar://10515467

llvm-svn: 145701

Add the 16-bit lane variants while I'm at it.

llvm-svn: 145693

llvm-svn: 145682

llvm-svn: 145681