constant pool ranges, as CPEIsInRange() makes conservative assumptions about
the potential alignment changes from branch adjustments. The verification,
on the other hand, runs after those branch adjustments are made, so the
effects on alignment are known and already taken into account. The sanity
check in verify should check the range directly instead.

llvm-svn: 89473

llvm-svn: 89443

llvm-svn: 89440

Fix codegen of conditional move of immediates. We were not making use of the immediate forms of cmov instructions at all.

llvm-svn: 89423

llvm-svn: 89414

assembly can confuse things utterly, as it's assumed that instructions in
inline assembly are 4 bytes wide. For Thumb mode, that's often not true,
so the calculations for when alignment padding will be present get thrown off,
ultimately leading to out of range constant pool entry references. Making
more conservative assumptions that padding may be necessary when inline asm
is present avoids this situation.

llvm-svn: 89403

llvm-svn: 89396

$ svn merge -c -89279 https://llvm.org/svn/llvm-project/llvm/trunk
--- Reverse-merging r89279 into '.':
U    lib/CodeGen/AsmPrinter/DwarfException.cpp
U    lib/Target/TargetLoweringObjectFile.cpp
$ svn merge -c -89270 https://llvm.org/svn/llvm-project/llvm/trunk
--- Reverse-merging r89270 into '.':
G    lib/CodeGen/AsmPrinter/DwarfException.cpp
G    lib/Target/TargetLoweringObjectFile.cpp

llvm-svn: 89379

fully specified at this level.  Subclasses of NLdStLN can specify selective
bit(s) for Inst{7-4}, as is done for VLD[234]LN* and VST[234]LN* inside
ARMInstrNEON.td.

llvm-svn: 89377

llvm-svn: 89369

llvm-svn: 89360

llvm-svn: 89337

llvm-svn: 89328

llvm-svn: 89326

llvm-svn: 89325

- Support mips1 like load/store of doubles:

Instead of:
  sdc $f0, X($3)
Generate:
  swc $f0, X($3)
  swc $f1, X+4($3)

llvm-svn: 89322

llvm-svn: 89316

exception table than DataRel.

llvm-svn: 89279

llvm-svn: 89273

Place the EH table in the __TEXT section on MachO. It saves space.

llvm-svn: 89270

Added getDefaultSubtargetFeatures method to SubtargetFeatures class which returns a correct feature string for given triple.

llvm-svn: 89236

llvm-svn: 89218

llvm-svn: 89214

contents of the block to be duplicated.  Use this for ARM Cortex A8/9 to
be more aggressive tail duplicating indirect branches, since it makes it
much more likely that they will be predicted in the branch target buffer.
Testcase coming soon.

llvm-svn: 89187

This is probably not confined to *just* these two things.

Anyway, the llvm-gcc front-end may look up the structure layout information for
an abstract type. That information will be stored into a table with the FE's
TD. Instruction combine can come along and also ask for information on that
abstract type, but for a separate TD (the one associated with the pass manager).

After the type is refined, the old structure layout information in the pass
manager's TD file is out of date. If a new type is allocated in the same space
as the old-unrefined type, then the structure type information in the pass
manager's TD file will be wrong, but won't know it.

Fix this by making the TD's structure type information an abstract type user.

llvm-svn: 89176

llvm-svn: 89143

alignment imm (in the same way). Fix asmprinting for non-darwin platforms.

llvm-svn: 89137

distinguish between them and the more generic instructions (add, mov, and ldr).

llvm-svn: 89108

llvm-svn: 89081

llvm-svn: 89076

is analyzable so it can be updated. If it's not, be safe and don't move the
block.

llvm-svn: 89022

llvm-svn: 89019

llvm-svn: 89011

0b1110 (ALways).  This is so that the disassembler decoder can distinguish among
BX_RET, BRIND, and BXr9.

llvm-svn: 89000

The large code model is documented at
http://www.x86-64.org/documentation/abi.pdf and says that calls should
assume their target doesn't live within the 32-bit pc-relative offset
that fits in the call instruction.

To do this, we turn off the global-address->target-global-address
conversion in X86TargetLowering::LowerCall(). The first attempt at
this broke the lazy JIT because it can separate the movabs(imm->reg)
from the actual call instruction. The lazy JIT receives the address of
the movabs as a relocation and needs to record the return address from
the call; and then when that call happens, it needs to patch the
movabs with the newly-compiled target. We could thread the call
instruction into the relocation and record the movabs<->call mapping
explicitly, but that seems to require at least as much new
complication in the code generator as this change.

To fix this, we make lazy functions _always_ go through a call
stub. You'd think we'd only have to force lazy calls through a stub on
difficult platforms, but that turns out to break indirect calls
through a function pointer. The right fix for that is to distinguish
between calls and address-of operations on uncompiled functions, but
that's complex enough to leave for someone else to do.

Another attempt at this defined a new CALL64i pseudo-instruction,
which expanded to a 2-instruction sequence in the assembly output and
was special-cased in the X86CodeEmitter's emitInstruction()
function. That broke indirect calls in the same way as above.

This patch also removes a hack forcing Darwin to the small code model.
Without far-call-stubs, the small code model requires things of the
JITMemoryManager that the DefaultJITMemoryManager can't provide.

Thanks to echristo for lots of testing!

llvm-svn: 88984

- Check memoperand alignment instead of checking stack alignment. Most load / store folding instructions are not referencing spill stack slots.
- Mark MOVUPSrm re-materializable.

llvm-svn: 88974

llvm-svn: 88964

llvm-svn: 88961

usage of block sizes and offsets.

llvm-svn: 88935

llvm-svn: 88933