llvm-svn: 93283

It was only being used by instructions with the t_addrmode_sp addressing mode,
and that is pattern matched in a way that guarantees SP is used. There is
never any register allocation done from this class.

llvm-svn: 93280

flag doesn't exist there, and this is an x86 test.

llvm-svn: 93279

Add a quick pass to optimize sign / zero extension instructions. For targets where the pre-extension values are available in the subreg of the result of the extension, replace the uses of the pre-extension value with the result + extract_subreg.

For now, this pass is fairly conservative. It only perform the replacement when both the pre- and post- extension values are used in the block. It will miss cases where the post-extension values are live, but not used.

llvm-svn: 93278

dumper doesn't really do what I want yet, but
at least it doesn't crash now.

llvm-svn: 93272

llvm-svn: 93270

llvm-svn: 93261

llvm-svn: 93259

in JT.

2) When cloning blocks for PHI or xor conditions, use
instsimplify to simplify the code as we go.  This allows us to 
squish common cases early in JT which opens up opportunities for
subsequent iterations, and allows it to completely simplify the
testcase.

llvm-svn: 93253

llvm-svn: 93251

llvm-svn: 93249

llvm-svn: 93247

llvm-svn: 93245

llvm-svn: 93244

on x86-64 linux with messages like this:
Error: Incorrect register `%r14' used with `l' suffix

llvm-svn: 93242

llvm-svn: 93235

to not touch Cygwin: the change caused llvm-gcc build failures due to
long double getting the wrong size.  Patch by Aaron Gray.

llvm-svn: 93234

llvm-svn: 93230

llvm-svn: 93229

llvm-svn: 93228

llvm-svn: 93227

llvm-svn: 93222

condition is a xor with a phi node.  This eliminates nonsense
like this from 176.gcc in several places:

 LBB166_84:
        testl   %eax, %eax
-       setne   %al
-       xorb    %cl, %al
-       notb    %al
-       testb   $1, %al
-       je      LBB166_85
+       je      LBB166_69
+       jmp     LBB166_85

This is rdar://7391699

llvm-svn: 93221

llvm-svn: 93220

instruction is copy like where the source and destination registers can
overlap. This is to be used by the coalescable to coalesce the source and
destination registers of instructions like X86::MOVSX64rr32. Apparently
some crazy people believe the coalescer is too simple.

llvm-svn: 93210

on branches by renaming it and checking for a branch at the call site.

llvm-svn: 93208

llvm-svn: 93206

Add manual ISD::OR fastisel selection routines. TableGen is no longer autogen them after 93152 and 93191.

llvm-svn: 93204

llvm-svn: 93203

codegen has no apparent problem with the trunc version of this, because it turns
into a simple subreg idiom

llvm-svn: 93202

trunc has multiple uses.  Codegen is not able to coalesce the subreg case 
correctly and so this leads to higher register pressure and spilling (see PR5997).

This speeds up 256.bzip2 from 8.60 -> 8.04s on my machine, ~7%.

llvm-svn: 93200

Consolidate ConvertGlobalValIDToValue, ConvertGlobalOrMetadataValIDToValue, and ConvertValIDToValue into a more powerful ConvertValIDToValue() that does all three's work

llvm-svn: 93197

llvm-svn: 93195

Implement the same interface as already available for dominators.

llvm-svn: 93194

Extend r93152 to work on OR r, r. If the source set bits are known not to overlap, then select as an ADD instead.

llvm-svn: 93191

llvm-svn: 93189

Shorten up this testcase.

llvm-svn: 93187

llvm-svn: 93185

This fixes PR5980.

llvm-svn: 93184

llvm-svn: 93183