Bjoern Haase wrote:
> 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.
The current CCmode back-ends (e.g. s390, but also i386 and others) handle
this problem by initially expanding into:
(parallel [(set (reg:SI 100) (minus:SI (reg:SI 101) (reg:SI 102)))
(clobber reg:CC_xxx CC)])
(set (reg:CC_xxx CC) (compare:CC (reg:SI 101) (reg:SI 102)))
and *also* offer another pattern, to be matched by combine:
(parallel [(set (reg:CC_xxx CC) (compare:CC (reg:SI 101) (reg:SI 102)))
(set (reg:SI 100) (minus:SI (reg:SI 101) (reg:SI 102)))])
See e.g. the "subsi3" expander vs. the "*subsi3_cc" and "*subsi3_cc2"
patterns in s390.md.
This works because combine will treat the initial parallel as a
'single-set' insn, and nearly all optimizations will be enabled.
Bye,
Ulrich
--
Dr. Ulrich Weigand
Linux on zSeries Development
[EMAIL PROTECTED]
