[committed] [0/3] Converting the v850 port away from cc0

[Jeff Law <law at redhat dot com>]

So as noted earlier, my son needed a project to occupy him, so he's
learning a bit of vi, git, & gcc by doing some of the easier parts of
cc0 -> REG_CC conversions.

I selected the v8 port as the first target based on the (flawed)
assumption that it would be the easiest.  It turns out a fair amount has
changed since I did the original v8 port many years ago.  Regardless,
it's done with a bit more head banging than expected.

Just a few notes for anyone who cares about this port.

Testing:

I haven't upstreamed all the bits I used for testing.

In the simulator/binutils/newlib I've given the simulator an extra
megabyte of memory.  The inconsistencies caused by collisions in the
various segments are painful to deal with.  However, I have not
upstreamed that change -- various comments lead me to believe the
current memory map may be derived from real hardware.

I haven't upstreamed a tweak in sim_fpu_neg where I think we're
mis-handling negation of NaNs.  I believe we're supposed to return a NaN
with the sign flipped.  But right now it just returns the original NaN.

There's a couple places in the simulator that are not 64 bit clean, in
particular handling of multiply and divide insns.  These are v850
specific issues and I'll likely upstream these fixes.  I suspect there's
other 64 bit issues it the code.  I'm not going to do a full audit of
the v850 simulator.

I'm pretty sure the v850 simulator mis-handles the "bins" instruction.
But it's also the case that I don't have any documentation on that insn,
so there may be some kind of restrictions that I'm not aware of.  For
testing purposes I disabled use of "bins".  But I'm not upstreaming that
hack.

I believe I've found a bug in the FNMAS handling in tree-ssa-mathopts.c.
 I still need to go through the relevant parts of the IEEE standard to
be sure.  In the mean time I've got a little hack that guards the
suspicious transformation on HONOR_SIGNED_ZEROs.

[Whoops, sent the 01-03 messages, but not the cover... ]

In the testsuite, there are many tests which simply use too much memory,
even with the extra megabyte added.  I'm currently guarding those with a
hack.  I'll probably upstream some kind of tweak here.

I'm pretty sure newlib's sprintf is not compliant enough to pass
builtin-sprintf.c's test.  So that's guarded as well.  Similarly there's
a guard for trapv tests which want to use fork and one or two other
oddballs.

So, with those caveats, the tests look really good now.  Essentially the
only differences between the trunk and a converted port are the
additional tests that we get a dumpfile from the compare-elim pass.

Code quality:

>From a code generation standpoint the trunk and the converted port are
essentially the same when comparing libgcc and newlib.  I've seen the
converted port miss a couple compare eliminations due to the CFG shape
changing after compare-elim.  But there's other cases where we're doing
a slightly better job at compare elimination -- in the end it's a wash.

Style:

The v8 does not have the ability to add two registers without changing
the condition codes.  So we don't expose the condition codes until after
reload, except as clobbers.  For insns where the condition codes are set
in a useful manner we have define_insn_and_split patterns to handle the
pre-reload and post-reload case (with and without clobbers respectively)
as well as patterns which set the condition codes.

A few insns do potentially set the condition codes in a useful way, but
I haven't bothered to describe the condition code handling as it's
unlikely to be all that important relative to the bloat they'd introduce
in v850.md (for example the divide instructions).

Future work

With cc0 eliminated on the v850 port, it can potentially convert to LRA.
 I've done light testing which looks promising, but haven't looked at it
extensively.   I'll probably do the conversion since it looks so easy.

If someone had an interest, they probably could do things like exploit
the C bit to improve 64bit arithmetic.  We're probably not using the
tst1 and similar instructions very aggressively either.  I'm not
planning to work on either of these issues.

I don't expect I'll do much, if anything, else on the v8 port.   My son
is currently working on the mechanical changes to convert the h8 port
away from cc0.

Jeff