llvm-svn: 108155

llvm-svn: 108154

llvm-svn: 108153

llvm-svn: 108152

llvm-svn: 108151

llvm-svn: 108150

support branching on x87 comparisons yet. This fixes PR7624.

llvm-svn: 108149

llvm-svn: 108148

llvm-svn: 108147

llvm-svn: 108146

llvm-svn: 108145

llvm-svn: 108144

llvm-svn: 108143

llvm-svn: 108142

llvm-svn: 108141

llvm-svn: 108140

llvm-svn: 108139

llvm-svn: 108138

llvm-svn: 108137

instcombine: fold (x & y) | (~x & z) and (x & y) ^ (~x & z) into ((y ^ z) & x) ^ z which is one instruction shorter. (PR6773)

before:
  %and = and i32 %y, %x
  %neg = xor i32 %x, -1
  %and4 = and i32 %z, %neg
  %xor = xor i32 %and4, %and

after:
  %xor1 = xor i32 %z, %y
  %and2 = and i32 %xor1, %x
  %xor = xor i32 %and2, %z

llvm-svn: 108136

llvm-svn: 108135

llvm-svn: 108134

llvm-svn: 108133

llvm-svn: 108132

llvm-svn: 108131

llvm-svn: 108130

that was actually useful here.

Chris, please double check that this is the correct interpretation. I was
pretty sure, and ran it by Nick as well.

llvm-svn: 108129

around by exempting enums from the check, but this doesn't handle a lot of
cases. A better approach is to directly check if the operator comes from
a macro expansion.

I've removed a reference to the rdar that originally led to the enum
suppression when removing it's overly contrived test case. Let me know if that
number or a more reasilistic test case involving enums is still needed.

llvm-svn: 108128

llvm-svn: 108127

llvm-svn: 108126

remove it, fixing PR6909.

llvm-svn: 108125

In the case of backtracking, the cached token lexer will be the only 
lexer on the stack, without this the token stack will be empty and EOF
won't be returned.

This fixes PR7072.

llvm-svn: 108124

llvm-svn: 108123

AggressiveAntiDepBreaker should not be using getPhysicalRegisterRegClass. An
instruction might be using a register that can only be replaced with one from
a subclass of getPhysicalRegisterRegClass.

With this patch we use getMinimalPhysRegClass. This is correct, but
conservative. We should check the uses of the register and select the
largest register class that can be used in all of them.

llvm-svn: 108122

Note that the example currently doesn't appear to work.

llvm-svn: 108121

This fixes PR7375.

llvm-svn: 108120

root cause of PR7481 and probably more, and has no apparent 
testcases.  I don't understand the logic here so I can't repair it.

llvm-svn: 108119

physical register can be allocated in the class of the virtual are sufficient.

I think that the test for virtual registers is more strict than it needs to be,
it should be possible to coalesce two virtual registers the class of one
is a subclass of the other.

llvm-svn: 108118

is involved.

llvm-svn: 108117

by Hans Vandierendonck from PR7605

llvm-svn: 108116