do illegal stuff around it.  No testcase because the issue is very fragile.

llvm-svn: 92167

llvm-svn: 92058

llvm-svn: 92054

Rearrange arguments.
No functional changes

llvm-svn: 92053

llvm-svn: 92052

llvm-svn: 92051

llvm-svn: 91996

llvm-svn: 91995

llvm-svn: 91993

llvm-svn: 91976

interesting part of this is the divrem changes, which are
already tested by CodeGen/X86/divrem.ll.

llvm-svn: 91975

static inline functions with macros.

llvm-svn: 91973

instead use the appropriate subreggy thing.  This generates identical
code on some large apps (thanks to Evan's cross class coalescing
stuff he did back in july).  This means that MOV16r0 can go away
completely in the future soon.

llvm-svn: 91972

Certain Thumb instructions require only SP (e.g. tSTRspi).

llvm-svn: 91944

because the Visual C++ build does not build .c files as C99

llvm-svn: 91935

Made LEA memory operands emit only 4 MCInst operands.
Made the scale operand equal 1 for instructions that have no
SIB byte.

llvm-svn: 91919

llvm-svn: 91914

Remove target attribute break-sse-dep. Instead, do not fold load into sse partial update instructions unless optimizing for size.

llvm-svn: 91910

llvm-svn: 91908

While converting one of the operands to a memory operand, we need to check if it is Legal and does not result into a cyclic dep.

llvm-svn: 91904

return partial registers. This affected the back-end lowering code some.

Also patch up some places I missed before in the "get" functions.

llvm-svn: 91880

with symbols in AuroraUX's global namespace.

llvm-svn: 91879

llvm-svn: 91878

X86 codegen that were causing circular symbol dependencies.

llvm-svn: 91871

get things like this out of the disassembler:

0x100000ecb: callq	-96

instead of:

0x100000ecb: callq	4294967200

rdar://7491123

llvm-svn: 91864

llvm-svn: 91841

llvm-svn: 91836

by allowing backends to override routines that will default
the JIT and Static code generation to an appropriate code model
for the architecture.

Should fix PR 5773.

llvm-svn: 91824

llvm-svn: 91823

llvm-svn: 91780

llvm-svn: 91778

llvm-svn: 91777

rename dprintf to dbgpritnf, in order to fix build with glibc (which already defines dprintf in stdio.h

llvm-svn: 91775

1. In indirect load/store insns , the name of fsr should be emitted as INDF.
2. include standard asmbly headers in generated asmbly.

llvm-svn: 91768

llvm-svn: 91764

llvm-svn: 91754

incarnations), integrated into the MC framework.  

The disassembler is table-driven, using a custom TableGen backend to 
generate hierarchical tables optimized for fast decode.  The disassembler 
consumes MemoryObjects and produces arrays of MCInsts, adhering to the 
abstract base class MCDisassembler (llvm/MC/MCDisassembler.h).

The disassembler is documented in detail in

- lib/Target/X86/Disassembler/X86Disassembler.cpp (disassembler runtime)
- utils/TableGen/DisassemblerEmitter.cpp (table emitter)

You can test the disassembler by running llvm-mc -disassemble for i386
or x86_64 targets.  Please let me know if you encounter any problems
with it.

llvm-svn: 91749

Based on patch by Michael Beck!

llvm-svn: 91745

- Move DisableScheduling flag into TargetOption.h
- Move SDNodeOrdering into its own header file. Give it a minimal interface that
  doesn't conflate construction with storage.
- Move assigning the ordering into the SelectionDAGBuilder.

This isn't used yet, so there should be no functional changes.

llvm-svn: 91727

MI was not being used but it was also not being deleted, so it was kept in the garbage list. The memory itself was freed once the function code gen was done.

Once in a while the codegen of another function would create an instruction on the same address. Adding it to the garbage group would work once, but when another pointer was added it would cause an assert as "Cache" was about to be pushed to Ts.

For a patch that make us detect problems like this earlier, take a look at

http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20091214/092758.html

With that patch we assert as soon and the new instruction is added to the garbage set.

llvm-svn: 91691