This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: How aggressive is CSE about removing redundant CC sets?
- From: Ulrich Weigand <weigand at i1 dot informatik dot uni-erlangen dot de>
- To: kazu at cs dot umass dot edu
- Cc: gcc at gcc dot gnu dot org
- Date: Sat, 14 Feb 2004 20:19:31 +0100 (CET)
- Subject: Re: How aggressive is CSE about removing redundant CC sets?
Kazu Hirata wrote:
>(Interestingly, the redundant compare
>insn went away when I flipped the order of the two sets in the first
>insn.)
This may be because the flipped order is the one that combine
prefers -- there's the following explicit assumption:
Many machines that don't use CC0 have insns that can both perform an
arithmetic operation and set the condition code. These operations will
be represented as a PARALLEL with the first element of the vector
being a COMPARE of an arithmetic operation with the constant zero.
The second element of the vector will set some pseudo to the result
of the same arithmetic operation.
(Now your special case is just a load-and-test, not an artithmetic
operation, but I wouldn't be surprised if the same held there as well.)
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.
(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.)
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 ...)
Bye,
Ulrich
--
Dr. Ulrich Weigand
weigand@informatik.uni-erlangen.de