This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Three old entries from PROBLEMS
<li value="110">Possible special combination pattern: If the two
operands to a comparison die there and both come from insns that are
identical except for replacing one operand with the other, throw away
those insns. Ok if insns being discarded are known 1 to 1. An andl
#1 after a seq is 1 to 1, but how should compiler know that?</li>
That would be:
add r4, r1, r2 (or sub by inverting the compare operands, or xor
if used in an equality/inequality comparison)
add r5, r1, r3
cmp r4, r5 -> cmp r2, r3
We don't do this, but it doesn't seem hard to do on the tree level (e.g.
in reassoc) or in combine for -fstrict-overflow. Nice trick, worth a
Bugzilla entry IMO.
I don't understand the last sentence.
<li value="117">Any number of slow zero-extensions in one loop, that
have their clr insns moved out of the loop, can share one register if
their original life spans are disjoint. But it may be hard to be sure
of this since the life span data that regscan produces may be hard to
interpret validly or may be incorrect after cse.</li>
That would be:
clr r7
clr r8
...
move strict-low-part(r7), r0
...
move strict-low-part(r8), r1 --> could reuse r7
This is not implemented but IMHO obsolete, most of the targets will just
use an AND to implement zero extension.
<li value="118">In cse, when a bfext insn refers to a register, if the
field corresponds to a halfword or a byte and the register is
equivalent to a memory location, it would be possible to detect this
and replace it with a simple memory reference.</li>
I think we do this in combine now.
Paolo