|  | Commit message (Collapse) | Author | Age | Files | Lines | 
|---|
| ... |  | 
| | 
| 
| 
| 
| 
| 
| | objc_retainBlock call is potentially responsible for copying
the block to the heap to extend its lifetime. rdar://10209613.
llvm-svn: 140814 | 
| | 
| 
| 
| 
| 
| | 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 | 
| | 
| 
| 
| 
| 
| 
| 
| | 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 | 
| | 
| 
| 
| 
| 
| | previous checkin.
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 | 
| | 
| 
| 
| 
| 
| 
| 
| | 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 | 
| | 
| 
| 
| 
| 
| | 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 | 
| | 
| 
| 
| 
| 
| | blocks to extract.
llvm-svn: 140168 | 
| | 
| 
| 
| 
| 
| | complete length.
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 | 
| | 
| 
| 
| 
| 
| | 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 | 
| | 
| 
| 
| 
| 
| 
| 
| | construct is changed when it is not.  (See included testcase.)
Patch by Xiaoyi Guo.
llvm-svn: 140072 | 
| | 
| 
| 
| | llvm-svn: 140026 | 
| | 
| 
| 
| | llvm-svn: 139842 | 
| | 
| 
| 
| 
| 
| | Spotted by inspection.
llvm-svn: 139768 | 
| | 
| 
| 
| 
| 
| | which could theoretically throw.
llvm-svn: 139710 | 
| | 
| 
| 
| 
| 
| | in memory relevant to the optimizer. rdar://10050579.
llvm-svn: 139708 | 
| | 
| 
| 
| 
| 
| | PR10920.
llvm-svn: 139583 | 
| | 
| 
| 
| | llvm-svn: 139579 | 
| | 
| 
| 
| | llvm-svn: 139574 | 
| | 
| 
| 
| | llvm-svn: 139571 | 
| | 
| 
| 
| | llvm-svn: 139565 | 
| | 
| 
| 
| 
| 
| 
| 
| | No tests; these changes aren't really interesting in the sense that the logic is the same for volatile and atomic.
I believe this completes all of the changes necessary for the optimizer to handle loads and stores correctly.  I'm going to try and come up with some additional testing, though.
llvm-svn: 139533 | 
| | 
| 
| 
| 
| 
| | default change.
llvm-svn: 139517 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| | better.
Don't immediately give up when an add operation can't be trivially
sign/zero-extended within a loop. If it has NSW/NUW flags, generate a
new expression with sign extended (non-recurrent) operand. As before,
if SCEV says that all sign extends are loop invariant, then we can
widen the operation.
llvm-svn: 139453 | 
| | 
| 
| 
| | llvm-svn: 139375 | 
| | 
| 
| 
| | llvm-svn: 139169 | 
| | 
| 
| 
| | llvm-svn: 139156 | 
| | 
| 
| 
| 
| 
| | the end of a function), now with less deleting stores before memcpy's.
llvm-svn: 139150 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| | init.trampoline and adjust.trampoline intrinsics, into two intrinsics
like in GCC.  While having one combined intrinsic is tempting, it is
not natural because typically the trampoline initialization needs to
be done in one function, and the result of adjust trampoline is needed
in a different (nested) function.  To get around this llvm-gcc hacks the
nested function lowering code to insert an additional parent variable
holding the adjust.trampoline result that can be accessed from the child
function.  Dragonegg doesn't have the luxury of tweaking GCC code, so it
stored the result of adjust.trampoline in the memory GCC set aside for
the trampoline itself (this is always available in the child function),
and set up some new memory (using an alloca) to hold the trampoline.
Unfortunately this breaks Go which allocates trampoline memory on the
heap and wants to use it even after the parent has exited (!).  Rather
than doing even more hacks to get Go working, it seemed best to just use
two intrinsics like in GCC.  Patch mostly by Sanjoy Das.
llvm-svn: 139140 | 
| | 
| 
| 
| 
| 
| | exception.
llvm-svn: 139117 | 
| | 
| 
| 
| 
| 
| | landingpad and terminator).
llvm-svn: 139090 |