preview / RFC: upcoming contributions from SuperH

[Joern Rennecke]

[Highpart life analysis]
> I don't really like this at all.  IMO your "highpart user" simply
> takes DImode inputs, and if you aren't describing that, then it is
> clear why you're losing.

Some of them say DImode, some don't.
SImode operations are different from DImode operations in that they can
assume that the inputs are all properly sign extended, and they are required
to produce a properly sign extended result.

The optimizers don't work quite right if the can't match a SImode logical
operation or SImode comparison.
Moreover, changing such operations to explicitly use DImode arguments
is not making the unnecessary sign extensions go away - rather the contrary:
in the case of logical operations, if they were described as
DImode operations, a specific truncation operation would be required
afterwards to satisfy TRULY_NOOP_TRUNCATION(32,64) == 0.
Furthermore, changing the mode of function arguments or memory addresses
has quite profound implications.

> What I would like to see instead is a pass that looks examines
> the dataflow and determines that if we move an extension backward
> in the flowgraph then (1) we can often get the extension for free,
> and (2) we eliminate possibly many extensions later.

That doesn't cover the case when a highpart is being computed but turns out
to be dead when function-wide data flow analysis is done.
I.e. in one block you compute a value in a way that involves a sign extsnsion,
and later you use that value in one or more other blocks - but you don't
use the highpart.  This is quite common, since addition is such a common
operation.

Folding an extension into an earlier operation can actually often be done
by combine (and yes, you need a zoo of patterns for that - but that's
true for your scheme too).

[ Handling sign extensions properly for SH5media32]
> Hopefully this would be fixed by the extension optimization pass as
> well.  I presume this is mips-like issues with extension and Pmode?

Yes, it is.  The indexed addressing mode always uses a 64 bit addition,
and the result is always checked in 64 bit.

Initial trials with Pmode == DImode showed very bad generated code and
also incorrect code generated due to a number of bugs in the expanders and
optimizers.  That was rh-2.96 based then, so some of the bugs might be fixed
by now, but I suspect there are still a number of them around.  Last I looked,
the mips maintainers had given up on Pmode == DImode for 32 bit ABI.
The extension optimization pass might address some of the code
quality issues, but it wouldn't address the correctness issues, nor would
it magically make the machine description work smoothly with that concept.

I don't know if this is also true for mips, but the SHmedia ABI also
dictates that arguments and return values of 32 bit or smaller which are
passed in general purpose registers are passed with the upper 32 bits as a
sign extension from bit 31.