This is the mail archive of the
mailing list for the GCC project.
Re: Handle MODE_CC in gen_lowpart_common
- From: "John David Anglin" <dave at hiauly1 dot hia dot nrc dot ca>
- To: gcc-patches at gcc dot gnu dot org
- Cc: geoffk at geoffk dot org
- Date: Mon, 12 May 2003 18:42:40 -0400 (EDT)
- Subject: Re: Handle MODE_CC in gen_lowpart_common
> 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
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
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
J. David Anglin firstname.lastname@example.org
National Research Council of Canada (613) 990-0752 (FAX: 952-6602)