The x86_mmx type is used for MMX intrinsics, parameters and
return values where these use MMX registers, and is also
supported in load, store, and bitcast.

Only the above operations generate MMX instructions, and optimizations
do not operate on or produce MMX intrinsics. 

MMX-sized vectors <2 x i32> etc. are lowered to XMM or split into
smaller pieces.  Optimizations may occur on these forms and the
result casted back to x86_mmx, provided the result feeds into a
previous existing x86_mmx operation.

The point of all this is prevent optimizations from introducing
MMX operations, which is unsafe due to the EMMS problem.

llvm-svn: 115243

false positive, at least on Darwin. I haven't filed this, but you can feel free.

llvm-svn: 115242

conversion heuristics to the old-style ones.

llvm-svn: 115239

use MC instructions in the printInstruction() method via the tablegen flag
for it rather than a #define prior to including the autogenerated bits.

llvm-svn: 115238

llvm-svn: 115225

llvm-svn: 115215

llvm-svn: 115214

llvm-svn: 115206

We do want to allow LoadPRE to perform LICM-like transformations: we already consider PHI nodes to be negligible for
code size (making this transform code size neutral), and it allows us to hoist values out of loops, which is always
a good thing.

llvm-svn: 115205

The bug that broke i386 linux has been fixed in r115191.

llvm-svn: 115204

llvm-svn: 115203

llvm-svn: 115198

fixes some cases where we were producing relocations with at symbol that
should use a section instead.

llvm-svn: 115194

llvm-svn: 115193

edited during emission.

If the basic block ends in a switch that gets lowered to a jump table, any
phis at the default edge were getting updated wrong. The jump table data
structure keeps a pointer to the header blocks that wasn't getting updated
after the MBB is split.

This bug was exposed on 32-bit Linux when disabling critical edge splitting in
codegen prepare.

The fix is to uipdate stale MBB pointers whenever a block is split during
emission.

llvm-svn: 115191

vs. ELF

llvm-svn: 115180

llvm-svn: 115179

llvm-svn: 115178

llvm-svn: 115177

llvm-svn: 115176

llvm-svn: 115175

llvm-svn: 115174

missed a bunch of files.  Here the rest.  Sorry about that.

llvm-svn: 115173

llvm-svn: 115172

llvm-svn: 115171

llvm-svn: 115170

llvm-svn: 115168

llvm-svn: 115165

llvm-svn: 115164

llvm-svn: 115163

llvm-svn: 115162

llvm-svn: 115161

llvm-svn: 115160

and output the dwarf line number tables.  This contains the code to emit and
encode the dwarf line tables from the previously gathered information in the
MCLineSection objects.  This contains all the details to encode the line and
address deltas into the dwarf line table.

To do this an MCDwarfLineAddrFragment has been added.

Also this moves the interface code out of Mach-O streamer into
MCDwarf so it should be useable by other object file formats.

There is now one call to be made from an MCObjectStreamer
EmitInstruction() method:
   MCLineEntry::Make(this, getCurrentSection());
to create a line entry after each instruction is assembled.

And one call call to be made from an MCObjectStreamer Finish() method:
   MCDwarfFileTable::Emit(this, DwarfLineSection);
when getContext().hasDwarfFiles() is true and is passed a object file specific
MCSection where to emit the dwarf file and the line tables.

This appears to now be correct for 32-bit targets, at least x86.  But the
relocation entries for 64-bit Darwin needs some further work which is next
up to work on.  So for now the 64-bit Mach-O target does not output the
dwarf file and line tables.

llvm-svn: 115157

llvm-svn: 115156

if we are given a Layout object, even in cases when the value is not fixed.
This will be needed by the final patch for the dwarf .loc support to size a
new MCDwarf fragment needed to build and emit dwarf line number tables.

llvm-svn: 115155

llvm-svn: 115154

for the dwarf .loc support to emit dwarf line number tables.

llvm-svn: 115153

llvm-svn: 115152

reduces the amount of malloc calls and may reduce memory overhead.

Some numbers:
ASTContext stats, clang -cc1 -disable-free -fsyntax-only Cocoa_h.m
without dynamic growth                          |  with dynamic growth
Number of memory regions: 3158                  |  Number of memory regions: 432
Bytes used: 12333185                            |  Bytes used: 12333185
Bytes allocated: 12935168                       |  Bytes allocated: 12800000
Bytes wasted: 601983 (includes alignment, etc)  |  Bytes wasted: 466815 (includes alignment, etc)

ASTContext stats, clang -cc1 -disable-free -fsyntax-only on clang's ASTReader.cpp
without dynamic growth                          |  with dynamic growth
Number of memory regions: 10987                 |  Number of memory regions: 551
Bytes used: 42910356                            |  Bytes used: 42910356
Bytes allocated: 45002752                       |  Bytes allocated: 44711936
Bytes wasted: 2092396 (includes alignment, etc) |  Bytes wasted: 1801580 (includes alignment, etc)

llvm-svn: 115151