Quoting Paolo Bonzini <bonz...@gnu.org>:
<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.
This would only be valid if the comparison is in an equality context
(or for special input operand ranges).
So (unless the target is CC0) you'd either have to use dataflow analysis
to look at all the contexts the comparison result is used in, or you'd need
a target hook to classify CCmode modes to check if they are used only
for equality comparisons and can have their inputs altered.
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.
If the target can actually write to partial registers and refer to the
entire register without undue delay, you won't need and zero_extend or
AND operation at all. So this is obsolete only to the extent that such
targets have become fewer / more arcane.
FWIW the ARC mxp had that feature, but it doesn't look like that port
will get into gcc mainline.
