This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]