Re: Implicit fractional conversion bug/missing feature

[Roger Sayle <roger at eyesopen dot com>]

Hi Andrea,

On Fri, 18 Mar 2005, Andrea wrote:
> I'm very new in porting gcc for new architectures. Currently I'm
> working on the port of an architecture not "byte addressable" but
> word32 addressable (BITS_PER_UNIT=32), like the c4x.

I'm a bit out of my depth on this one, so I'll make a few comments,
reveal my total ignorance of GCC's support for "unusual" architectures
and then hopefully some other maintainer will review your change
to convert.c.


> I know that my architecture doesn't fit very well in what gcc expects.

The design of GCC's backend interfaces allows for a number of alternate
implementations for a given architecture.  A port maintainer can decide
to represent their hardware as a "cc0" target, or using define_peephole,
or use RTL prologue/epilogue expanders, or provide a DFA scheduler
description, etc...  Many of these are implementation decisions, but
an important few come under the subset of "virtualization" or "hardware
abstraction".  In the table in http://gcc.gnu.org/backends.html, a few
of the columns are intrinsic to the hardware, whilst others a metrics
of how well written a backend is.

Just because a target doesn't have DImode registers, doesn't mean that
it can't "claim" that it does and provide suitable "expanders" and/or
"splitters" to emulate these instructions.  Targets may often provide
SFmode and DFmode patterns even though they require floating point
emulation in software, but more importantly there's precedence for
targets claiming to be "byte addressable" even when they require a
sequence of shift and mask operations to implement this.  I believe
the canonical example is the "alpha" (anyone?).  Hence, I believe
(and someone correct me if I'm worng), the "N" property in backends.html
is a design decision rather than an intrinsic requirement.

The reason I raise this issue is that there's a clear preference for
GCC backends to (claim to) be byte addressable.  The ageing c4x port
has been a source of headaches in this respect and I wouldn't be
surprised if support for targets without such virtualization was
eventually dropped.  Particularly concerning with the problems that
you're running into is that they are occurring at the target-independent
tree-level, and require a change in "convert.c" which is almost a
front-end routine.  Whereas traditionally GCC's RTL optimizers had
support for machine specific idioms and nuances, one of the raisons
d'etre of GCC's new tree-ssa optimizers is that they are intended to
abstract away machine-specific details.  They can perform DImode and
DFmode optimizations, whether or not the target supports such operations
directly.

I just thought I'd raise the issue, in the hopes that that your
new port is making the "beginner's mistake" of simply encoding the
instruction set of the new processor without making concessions to
the rest of the compiler.  There may be very strong reasons for
attempting the style of port that you're writing, but I think it
would be helpful to rule out much simpler alternatives before
embarking on the world of pain to make tree-ssa and the RTL optimizers
aware of user visible "modes", that can't be read/written/spilled
directly to memory.



Perhaps I'm being overly pessimistic, but I'd like to hear from a
global write maintainer that this the "correct thing to do", before
I start approving tree-level middle-end changes that test target
macros for "unusual" architectures.  It's not even clear if your
port represents "real silicon" or is a hypothetical study on how
poorly development tools generate code for crippled ISAs.  Clearly,
the decision to introduce #ifdefs into GCC's code base is affected
by whether this port would help a significant user base, and whether
there's even an intention to contribute this port to the FSF tree.

Thoughts?

Roger
--