History log of /llvm-project/llvm/lib/CodeGen/MachineSink.cpp (Results 226 – 250 of 275)
Revision (<<< Hide revision tags) (Show revision tags >>>) Date Author Comments
# 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 ...


1234567891011