Handle MODE_CC in gen_lowpart_common

[John David Anglin]

Geoff,

> I'm concerned that this patch assumes semantics of MODE_CC which may
> not be valid for all ports and which are known to be invalid (but
> perhaps harmlessly so) for at least one port.

On the PA, patterns were added last year to set reg:CCFP to a
known state, either 0 or 1.  See
<http://gcc.gnu.org/ml/gcc-patches/2002-09/msg00038.html> and
<http://gcc.gnu.org/ml/gcc-patches/2002-09/msg00040.html> for
details on why this was done.

It is my understanding that Roger's patch only affects ports that
have patterns such as these.  Ports won't have these patterns if
the semantics of a MODE_CC register doesn't allow them.  For
example, we use MODE_CC for integer comparisons but we don't define
the patterns for reg:CC.  This doesn't appear to cause problems.

> I agree that backends should choose the representation that best
> matches their hardware's behaviour; I think this patch would be
> at best useless and at worst harmful if this was done.

This is not what I saw in my analysis of PR 8705.  With Roger's
patch <http://gcc.gnu.org/ml/gcc-patches/2003-04/msg01757.html>,
the testcase associated with the PR is simplified in the cse
pass.  Prior to fixing the PR, the loop in the testcase was not
simplified at all.  After the PR fix, the testcase is simplified
in combine.  Why is earlier simplication of if_then_else rtx's not
beneficial?

Dave
-- 
J. David Anglin                                  dave.anglin@nrc-cnrc.gc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6602)