[patch] h8300: Fix target/11805

[Hans-Peter Nilsson]

Finally got around to reply to this, sigh.

On Thu, 21 Aug 2003, Zack Weinberg wrote:
> Alexandre Oliva <aoliva@redhat.com> writes:
>
> > 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.
>
> That's all fine from the point of view of a single target maintainer.
> Roger's taking the global view, where having more than one way to do
> something is bad.  The cc0 mechanism has bitrotted to the point that
> all cc0 targets were broken for several months last year and no one
> noticed, which says to me that it's outlived its usefulness.

When was this time-period?  I can't locate such a period in my
logs, looking at last year's logs for CRIS and mn10300.  Maybe
this happened before the spotlight on simulator-enabled
toolchains?

I contest your statement.  Using (cc0) is useful and a
straightforward way to describe the condition code machinery for
such machines.

There are two bad things about the cc0 machinery looking at it
from RTL transforms: the necessity to keep cc0 setter and user
next to each other, and the necessity to test cc0_rtx now and
then.  I'd agree that the former is no small thing when doing
transformations at the RTL level; it'd be good to be able to
replace it with something better, something that doesn't need
changes to the generic RTL parts.

Still, the right thing is really not to force all cc0 ports to
use the generic (reg:CC) machinery, like with i386.  The i386
could live with it because actually not many instructions change
cc0 there; the move insns for example.  Can you say that the
i386 back end is clearer and easier to maintain after that
change?  It was necessary for performance, though.

By claiming to take a global view, you need to consider the back
ends *and* the (RTL) front end, not just claiming that the back
ends just have to cope with what's best for the front end.

> > 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.
>
> This is a real problem.  I have been idly thinking about a model in
> which the initial RTL claims that there is no condition code; instead
> there are compare-and-branch insns that (if they were output) would
> produce a pair of machine instructions.

You have been idly thinking about reinventing the cbranch model
that Bernd Schmidt implemented (though IIRC incomplete)?

I have a feeling that this conversation has taken place before.
;-)  Right, see <URL:http://gcc.gnu.org/ml/gcc/2001-01/msg01834.html>
where RTH summed up (still) current status.

brgds, H-P