Re: How aggressive is CSE about removing redundant CC sets?

[Kazu Hirata <kazu at cs dot umass dot edu>]

Hi Ulrich,

> Generally speaking, from my experiences in converting s390 to CCmode,
> you should expand all insns first to patterns that only describe the
> operation being done, with an unspecific (clobber (reg CC)) added.
> (This allows many optimizations to work that are written to consider
> only single_set-type instructions.)
> 
> Then, in a second pattern, provide a PARALLEL where the first member
> is an explicit SET of the CC register to the correct result, and the
> second member is the original operation of the insn.  This will be
> chosen by combine if the CC value is of interest.

This is very helpful.  I'll go this way.  So far, I've put a CC
clobber for every insn except compare.  That is, compare is the only
way to generate a condition for conditional jumps.  The generated code
is not of good quality yet, but the testsuite result is already pretty
good.

> (Optionally, it may be beneficial to provide a third pattern that
> has *only* the SET CC, and a (clobber (match_scratch)) to do away
> with the main output; this will be chosen if you're performing the
> operation only to look at the CC.)

I'm sorry, I don't quite understand.  Could you give me an example
pattern?  Something like this?

  (parallel [(set (reg CC) (compare (reg XX) (const_int 0)))
             (clobber (what goes here?))])

> While it would certainly be easier for the back end to just have a
> single pattern that describes the exact semantics of the instruction,
> this doesn't lead to optimal results due to various assumptions in
> the middle end.  (At least this is the way it used to be -- maybe
> it's different now ...)

One day we only have to define exact semantics of each instruction,
and GCC will generate optimal DImode computation, etc. :-)

Kazu Hirata