RFC: (use) useful for avoiding unnecessary compare instructions during cc0->CCmode ?!

[Björn Haase <bjoern dot m dot haase at web dot de>]

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