[patch] h8300: Fix target/11805

Roger Sayle roger@eyesopen.com
Fri Aug 22 14:41:00 GMT 2003


Hi Kazu,
> > I certainly don't want this to hold up your patch, but I was just
> > wondering whether you had any long-term plans to transition to MODE_CC
> > or BImode condition codes?
>
> I don't have a plan at this moment.  If I am to move away from cc0, I
> would probably need help from other people.  As Alex has already
> pointed out, my main concern is whether code quality stays the same.
> If every insn carries a clobber of the cc reg, some optimization
> passes may not like that.  Elimination of redundant test instructions
> is part of code quality.

Indeed.  This is perhaps the major advantage of creating even an
experimental MODE_CC backend for h8300, is that it will allow a
comparison against the cc0 backend.  By comparing the code generated
by both backends we can identify deficiencies in GCC's RTL optimizers.
Finding places where cc0 does better than MODE_CC will help improve
the code we generate for x86, PPC, etc..., and finding places where
MODE_CC does better than cc0 could be used to help h8300.

Certainly, MODE_CC is far better tested than cc0, and almost all
new RTL optimizations are developed on MODE_CC machines, only porting
to cc0 afterwards, if at all!  Theoretically, MODE_CC RTL can represent
everything that can be represented in cc0 RTL and more, and any reduction
in code quality is a real GCC bug rather than a fundamental limitation.
Ultimately, a MODE_CC port can generate better code than a cc0 port
could for h8300-like targets.

Even if in the end, you decide to keep h8300 a cc0 target, we'll finally
resolve the question over how much benefit we get from cc0's maintenance
burden.


Anyway, by planting the acorn of an idea in people's minds, my work here
is done.  I will also add that if a company like SuperH who are supporting
RedHat to develop/improve cc0 backends could fund a side-by-side MODE_CC
vs. cc0 evaluation, both that port and the entire compiler would benefit!
Just a thought :>

Roger
--



More information about the Gcc-patches mailing list