r140966.

llvm-svn: 140969

but not load instructions. Noticed by inspection.

llvm-svn: 140966

We want heuristics to be based on accurate data, but more importantly
we don't want llvm to behave randomly. A benign trunc inserted by an
upstream pass should not cause a wild swings in optimization
level. See PR11034. It's a general problem with threshold-based
heuristics, but we can make it less bad.

llvm-svn: 140919

llvm-svn: 140916

llvm-svn: 140875

InstCombine was incorrectly considering the conversion of the constant
zero to be unsafe.

We want to transform:
define float @bar(float %x) nounwind readnone optsize ssp {
  %conv = fpext float %x to double
  %cmp = fcmp olt double %conv, 0.000000e+00
  %conv1 = zext i1 %cmp to i32
  %conv2 = sitofp i32 %conv1 to float
  ret float %conv2
}

Into:
define float @bar(float %x) nounwind readnone optsize ssp {
  %cmp = fcmp olt float %x, 0.000000e+00   ; <---- This
  %conv1 = zext i1 %cmp to i32
  %conv2 = sitofp i32 %conv1 to float
  ret float %conv2
}


rdar://10215914

llvm-svn: 140869

llvm-svn: 140865

catch or repeated filter clauses.  Teach instcombine a bunch
of tricks for simplifying landingpad clauses.  Currently the
code only recognizes the GNU C++ and Ada personality functions,
but that doesn't stop it doing a bunch of "generic" transforms
which are hopefully fine for any real-world personality function.
If these "generic" transforms turn out not to be generic, they
can always be conditioned on the personality function.  Probably
someone should add the ObjC++ personality function.  I didn't as
I don't know anything about it.

llvm-svn: 140852

llvm-svn: 140821

handle the case where the retain is in a different basic block.
rdar://10210274.

llvm-svn: 140815

objc_retainBlock call is potentially responsible for copying
the block to the heap to extend its lifetime. rdar://10209613.

llvm-svn: 140814

Clean up uses of switch instructions so they are not dependent on the operand ordering.  Patch by Stepan Dyatkovskiy.

llvm-svn: 140803

llvm-svn: 140769

Rewriting the entire loop nest now requires -enable-lsr-nested.
See PR11035 for some performance data.
A few unit tests specifically test nested LSR, and are now under a flag.

llvm-svn: 140762

llvm-svn: 140670

Stop emitting instructions with the name "tmp" they eat up memory and have to be uniqued, without any benefit.

If someone prefers %tmp42 to %42, run instnamer.

llvm-svn: 140634

split landingpad instructions into a PHI node.
PR11016

llvm-svn: 140592

Disabling aggressive LSR saves compilation time, and with the new
indvars behavior usually improves performance.

llvm-svn: 140590

llvm-svn: 140583

The minor bug heuristic was noticed by inspection. I added the
isLoser/isValid helpers because they will become more
important with subsequent checkins.

llvm-svn: 140580

No test case. Noticed by inspection and I doubt it ever affects the
outcome of the overall heuristic, let alone final codegen.

llvm-svn: 140431

llvm-svn: 140327

Make sure IPSCCP never marks a tracked call as overdefined in SCCPSolver::ResolvedUndefsIn.  If we do, we can end up in a situation where a function is resolved to return a constant, but the caller is marked overdefined, which confuses the code later.

<rdar://problem/9956541> (again).

llvm-svn: 140210

Some passes require breaking critical edges before they're called. Don't
segfault because of that.

llvm-svn: 140196

Place the check for an exit landing pad where it will be run on both code paths through the if-then-else.

llvm-svn: 140195

The landing pad must accompany the invoke when it's extracted. However, if it
does, then the loop isn't properly extracted. I.e., the resulting extraction has
a loop in it. The extracted function is then extracted, etc. resulting in an
infinite loop.

llvm-svn: 140193

llvm-svn: 140176

extract its associated landing pad block as well. However, that landing pad
block may have more than one predecessor. So split the landing pad block so that
individual landing pads have only one predecessor.

This type of transformation may produce a false positive with bugpoint.

llvm-svn: 140173

llvm-svn: 140172

llvm-svn: 140169

llvm-svn: 140168

llvm-svn: 140167

llvm-svn: 140164

llvm-svn: 140156

llvm-svn: 140154

GCOVLines is always accessed through a StringMap where the key is FileName.

llvm-svn: 140151

There is no need to write a local utility routine to find subprogram info if the utility routine is already available in DebugInfo.

llvm-svn: 140145

llvm-svn: 140094

extract the landing pad block. Otherwise, there will be a situation where the
invoke's unwind edge lands on a non-landing pad.

We also forbid the user from extracting the landing pad block by itself. Again,
this is not a valid transformation.

llvm-svn: 140083

Fix an infinite loop where a transform in InstCombiner::visitAnd claims a construct is changed when it is not.  (See included testcase.)

Patch by Xiaoyi Guo.

llvm-svn: 140072