This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [patch] h8300: Fix target/11805
- From: Alexandre Oliva <aoliva at redhat dot com>
- To: Roger Sayle <roger at eyesopen dot com>
- Cc: Kazu Hirata <kazu at cs dot umass dot edu>, gcc-patches at gcc dot gnu dot org
- Date: 21 Aug 2003 16:42:53 -0300
- Subject: Re: [patch] h8300: Fix target/11805
- Organization: GCC Team, Red Hat
- References: <Pine.LNX.4.44.0308211015040.16273-100000@www.eyesopen.com>
On Aug 21, 2003, Roger Sayle <roger@eyesopen.com> wrote:
> Sorry to ask, but are there any plans to upgrade the h8300 backend from
> a cc0 target to a new style MODE_CC target?
I don't think this would be a good idea. The h8300 is one of those
machines in which most instructions modify the condition codes, and
you can take advantage of the set values by omitting additional
compare instructions.
My understanding is that MODE_CC is more suited to targets in which
only a few instructions set condition codes, in general instructions
designed explicitly to for `compare' purposes. Such platforms will
often model the condition code bits present in some control register
as a fixed register, or use general-purpose or predicate registers as
the outputs of compare instructions.
Forcing a port in which most instructions set condition codes would
pretty much force every instruction that modifies them to be
implemented as a parallel that, besides its intended action, sets the
condition code register according to the side effects of the
operation, which significantly hinder GCC's ability to optimize the
code, or at least clobbers it (the x86 approach), which doesn't have
as much impact in optimization, but doesn't enable redundant compares
to be eliminated without significant effort.
> I know Alex Oliva is actively working on a new cc0 port(!?)
It was not a new port, but rather an extension to a pre-existing
cc0-using port.
> PR target/11805 reveals that cc0 isn't a perfect model for the h8300's
> condition codes, as clearly not all instructions set all of the flag
> bits.
This is something that can be fixed with additional values for the
cc attribute, in case this bug is not just a mismatch between the
cc attribute associated with some instruction and its actual
behavior. I haven't actually looked at the code.
--
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer aoliva@{redhat.com, gcc.gnu.org}
CS PhD student at IC-Unicamp oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist Professional serial bug killer