Hi,
I have thinking about how to overcome part of the "double-setter" difficulties
that arise when implementing cc0->CCmode conversion for a couple of targets:
IIUC correctly one of the two or three difficulties with cc0->CCmode
conversion is, that combine in it's present form is not able to
recognize that in a sequence like
(parallel[
(set reg:SI 100) (minus:SI (reg:SI 101) (reg:SI 102))
(set reg:CC_xxx CC) (compare (reg:SI 101) (reg:SI 102)))])
((set reg:CC_xxx CC) (compare (reg:SI 101) (reg:SI 102)))
the compare instruction could be avoided. IIUC it is presently suggested to
make use of *many* peephole2 patterns for solving this problem.
IIUC the key reason why present combine would miss the oportunity is that
many optimizations are not possible for "double-set" instructions.
In order to overcome this problem, it seems to be a possible approach to
expand double-set instructions that, e.g., leave the condition code in
a useful state to sequences containing "announce" instructions. I.e. expand
would insert two instructions after the double-set instruction that contain
the two individual sets and an additional "use" statement. I.e. above
sequence after expand then would look like
(parallel[
(set reg:SI 100) (minus:SI (reg:SI 101) (reg:SI 102))
(set reg:CC CC_xxx) (compare (reg:SI 101) (reg:SI 102)))])
(parallel[ (set reg:SI 100) (minus:SI (reg:SI 101) (reg:SI 102))
(use (reg:SI 100) ])
(parallel[ (set reg:CC_xxx CC) (compare (reg:SI 101) (reg:SI 102)))
(use (reg:CC])
((set reg:CC_xx CC) (compare (reg:SI 101) (reg:SI 102)))
. The patterns for the "announce" instructions would never generate any
assembly output and would have length "0". They are merely used for
communicating to the mid-end that a double-set instruction has a possibly
useful side-product.
When inserting such "announce" instructions, I think that even the present
combiner will be able to realize that the second compare instruction is not
necessary.
I have confirmed with another example of double-set instructions (divmodsi4
for the AVR target) that above approach indeed works. It seems, however, that
what one is using is kind of an undocumented side-effect that could be
subject to change in future releases. I.e. the documentation on (use)
presently "warns" that some optimization *could* take place when using the
(use) statements, resulting in bugs when using (use) in a wrong way.
I think that it would be helpful to make this partially documented behaviour
of the (use) clauses an official feature. I.e. I think that it would help to
agree on that the optimizations the present documentation "warns" of, "are
supposed" take place. (Maybe this is already commonly agreed on.?)
Comments?
Yours,
Bj�rn
