Three old entries from PROBLEMS

[Paolo Bonzini]

>    <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