#
25b6068b |
| 18-Aug-2010 |
Evan Cheng <evan.cheng@apple.com> |
If any def of a machine-sink candidate has local uses, it's obviously not safe to sink it to a successor block. This bug has been hidden because a later check for critical-edge disable these illegal
If any def of a machine-sink candidate has local uses, it's obviously not safe to sink it to a successor block. This bug has been hidden because a later check for critical-edge disable these illegal optimizations. This patch should significantly reduce the amount of time spent on checking dominator information for obviously unsafe sinking.
llvm-svn: 111450
show more ...
|
#
a7aed186 |
| 06-Aug-2010 |
Owen Anderson <resistor@mac.com> |
Reapply r110396, with fixes to appease the Linux buildbot gods.
llvm-svn: 110460
|
#
bda59bd2 |
| 06-Aug-2010 |
Owen Anderson <resistor@mac.com> |
Revert r110396 to fix buildbots.
llvm-svn: 110410
|
#
755aceb5 |
| 05-Aug-2010 |
Owen Anderson <resistor@mac.com> |
Don't use PassInfo* as a type identifier for passes. Instead, use the address of the static ID member as the sole unique type identifier. Clean up APIs related to this change.
llvm-svn: 110396
|
#
a57b97e7 |
| 21-Jul-2010 |
Owen Anderson <resistor@mac.com> |
Fix batch of converting RegisterPass<> to INTIALIZE_PASS().
llvm-svn: 109045
|
#
e41e40f6 |
| 25-Jun-2010 |
Bill Wendling <isanbard@gmail.com> |
- Reapply r106066 now that the bzip2 build regression has been fixed. - 2010-06-25-CoalescerSubRegDefDead.ll is the testcase for r106878.
llvm-svn: 106880
|
#
ef5a4383 |
| 23-Jun-2010 |
Daniel Dunbar <daniel@zuster.org> |
Revert r106066, "Create a more targeted fix for not sinking instructions into a range where it"... it causes bzip2 to be miscompiled by Clang.
Conflicts:
lib/CodeGen/MachineSink.cpp
llvm-svn: 106
Revert r106066, "Create a more targeted fix for not sinking instructions into a range where it"... it causes bzip2 to be miscompiled by Clang.
Conflicts:
lib/CodeGen/MachineSink.cpp
llvm-svn: 106614
show more ...
|
#
d71bd636 |
| 16-Jun-2010 |
Bill Wendling <isanbard@gmail.com> |
Improve comment to include that the use of a preg is also verboten in this situation.
llvm-svn: 106119
|
#
8c0cf099 |
| 15-Jun-2010 |
Bill Wendling <isanbard@gmail.com> |
Create a more targeted fix for not sinking instructions into a range where it will conflict with another live range. The place which creates this scenerio is the code in X86 that lowers a select inst
Create a more targeted fix for not sinking instructions into a range where it will conflict with another live range. The place which creates this scenerio is the code in X86 that lowers a select instruction by splitting the MBBs. This eliminates the need to check from the bottom up in an MBB for live pregs.
llvm-svn: 106066
show more ...
|
#
01edd682 |
| 03-Jun-2010 |
Jim Grosbach <grosbach@apple.com> |
Cleanup 80-column and trim trailing whitespace
llvm-svn: 105435
|
#
f82aea63 |
| 03-Jun-2010 |
Bill Wendling <isanbard@gmail.com> |
Machine sink could potentially sink instructions into a block where the physical registers it defines then interfere with an existing preg live range.
For instance, if we had something like these ma
Machine sink could potentially sink instructions into a block where the physical registers it defines then interfere with an existing preg live range.
For instance, if we had something like these machine instructions:
BB#0 ... = imul ... EFLAGS<imp-def,dead> test ..., EFLAGS<imp-def> jcc BB#2 EFLAGS<imp-use>
BB#1 ... ; fallthrough to BB#2
BB#2 ... ; No code that defines EFLAGS jcc ... EFLAGS<imp-use>
Machine sink will come along, see that imul implicitly defines EFLAGS, but because it's "dead", it assumes that it can move imul into BB#2. But when it does, imul's "dead" imp-def of EFLAGS is raised from the dead (a zombie) and messes up the condition code for the jump (and pretty much anything else which relies upon it being correct).
The solution is to know which pregs are live going into a basic block. However, that information isn't calculated at this point. Nor does the LiveVariables pass take into account non-allocatable physical registers. In lieu of this, we do a *very* conservative pass through the basic block to determine if a preg is live coming out of it.
llvm-svn: 105387
show more ...
|
#
7ee730eb |
| 02-Jun-2010 |
Bill Wendling <isanbard@gmail.com> |
Compulsive reformating. No functionalitical changes.
llvm-svn: 105359
|
#
c90f51c0 |
| 13-May-2010 |
Dan Gohman <gohman@apple.com> |
Teach MachineLICM and MachineSink how to clear kill flags conservatively when they move instructions.
llvm-svn: 103737
|
Revision tags: llvmorg-2.7.0 |
|
#
cdc3df48 |
| 15-Apr-2010 |
Jakob Stoklund Olesen <stoklund@2pi.dk> |
Avoid sinking machine instructions into a loop.
MachineLoopInfo is already available when MachineSinking runs, so the check is free.
There is no test case because it would require a critical edge i
Avoid sinking machine instructions into a loop.
MachineLoopInfo is already available when MachineSinking runs, so the check is free.
There is no test case because it would require a critical edge into a loop, and CodeGenPrepare splits those. This check is just to be extra careful.
llvm-svn: 101420
show more ...
|
#
20b71e28 |
| 13-Apr-2010 |
Jakob Stoklund Olesen <stoklund@2pi.dk> |
Teach MachineSinking to handle easy critical edges.
Sometimes it is desirable to sink instructions along a critical edge:
x = ... if (a && b) ... else use(x);
The 'a && b' condition creates a crit
Teach MachineSinking to handle easy critical edges.
Sometimes it is desirable to sink instructions along a critical edge:
x = ... if (a && b) ... else use(x);
The 'a && b' condition creates a critical edge to the else block, but we still want to sink the computation of x into the block. The else block is dominated by the parent block, so we are not pushing instructions into new code paths.
llvm-svn: 101165
show more ...
|
#
918a90a3 |
| 05-Apr-2010 |
Dan Gohman <gohman@apple.com> |
Don't do code sinking on unreachable blocks. It's unprofitable and hazardous.
llvm-svn: 100455
|
#
2061c841 |
| 05-Mar-2010 |
Dale Johannesen <dalej@apple.com> |
Fix some more places where dbg_value affected codegen.
llvm-svn: 97765
|
#
62e795ab |
| 02-Mar-2010 |
Evan Cheng <evan.cheng@apple.com> |
Swap parameters of isSafeToMove and isSafeToReMat for consistency.
llvm-svn: 97578
|
#
b06015aa |
| 09-Feb-2010 |
Chris Lattner <sabre@nondot.org> |
move target-independent opcodes out of TargetInstrInfo into TargetOpcodes.h. #include the new TargetOpcodes.h into MachineInstr. Add new inline accessors (like isPHI()) to MachineInstr, and start u
move target-independent opcodes out of TargetInstrInfo into TargetOpcodes.h. #include the new TargetOpcodes.h into MachineInstr. Add new inline accessors (like isPHI()) to MachineInstr, and start using them throughout the codebase.
llvm-svn: 95687
show more ...
|
#
4b7aa248 |
| 05-Jan-2010 |
David Greene <greened@obbligato.org> |
Change errs() to dbgs().
llvm-svn: 92593
|
#
974e12b2 |
| 25-Oct-2009 |
Nick Lewycky <nicholas@mxc.ca> |
Remove includes of Support/Compiler.h that are no longer needed after the VISIBILITY_HIDDEN removal.
llvm-svn: 85043
|
#
02d5f77d |
| 25-Oct-2009 |
Nick Lewycky <nicholas@mxc.ca> |
Remove VISIBILITY_HIDDEN from class/struct found inside anonymous namespaces. Chris claims we should never have visibility_hidden inside any .cpp file but that's still not true even after this commit
Remove VISIBILITY_HIDDEN from class/struct found inside anonymous namespaces. Chris claims we should never have visibility_hidden inside any .cpp file but that's still not true even after this commit.
llvm-svn: 85042
show more ...
|
Revision tags: llvmorg-2.6.0 |
|
#
b0db9917 |
| 19-Oct-2009 |
Dan Gohman <gohman@apple.com> |
Fix a typo in a comment.
llvm-svn: 84504
|
#
20a327b3 |
| 19-Oct-2009 |
Dan Gohman <gohman@apple.com> |
Change a few instance variables to be local variables.
llvm-svn: 84503
|
#
87b02d5b |
| 09-Oct-2009 |
Dan Gohman <gohman@apple.com> |
Factor out LiveIntervalAnalysis' code to determine whether an instruction is trivially rematerializable and integrate it into TargetInstrInfo::isTriviallyReMaterializable. This way, all places that n
Factor out LiveIntervalAnalysis' code to determine whether an instruction is trivially rematerializable and integrate it into TargetInstrInfo::isTriviallyReMaterializable. This way, all places that need to know whether an instruction is rematerializable will get the same answer.
This enables the useful parts of the aggressive-remat option by default -- using AliasAnalysis to determine whether a memory location is invariant, and removes the questionable parts -- rematting operations with virtual register inputs that may not be live everywhere.
llvm-svn: 83687
show more ...
|