sh64-elf (SH5) port

[Richard Sandiford]

Alexandre Oliva <aoliva@redhat.com> writes:
> [Replying in public because I think these points are important; I hope
> you don't mind, Richard.]
> On Feb  5, 2002, Richard Sandiford <rsandifo@redhat.com> wrote:
> > Alexandre Oliva <aoliva@redhat.com> writes:
> >> To wit, see the ugliness of the clean up code I had to introduce in
> >> OVERRIDE_OPTIONS to tell GCC that the sh-elf assembler does not
> >> support `.quad':
> >> 
> >> {									\
> >> /* Only the sh64-elf assembler fully supports .quad properly.  */\
> >> targetm.asm_out.aligned_op.di = NULL;				\
> >> targetm.asm_out.unaligned_op.di = NULL;				\
> >> }									\
> 
> > Hmm, what's ugly about it?  (Apart from the fact that OVERRIDE_OPTIONS
> > is still a macro rather than a function?)
> 
> Two reasons:
> 
> (i) it hides the actual values of these variables for certain
> configurations, which is exactly what the targetm structure was
> supposed to expose in a single place.

I thought the idea was more about exposing the target-specific parts to
the rest of the compiler, and the target structure does do that in a
single place.  You still have to do some cross-referencing when reading
the back-end code, but you have to do that now as well.

Case in point: MIPS's HARD_REGNO_MODE_OK, which uses an array that's set
up in OVERRIDE_OPTIONS.  I think that's a neat way of doing things,
since the definition never changes once you've parsed the cli options.
Why work it out from target flags every time?

[Personally, I think it'd be neater to set up the whole structure in
OVERRIDE_OPTIONS rather than using #undef/#define pairs.  Then you'd
have more information in one place textually as well as structurally.
But that's probably just me.]

> (i) it makes it harder for anyone to rearrange targetm into
> sub-structures or so when (note, not if, when!) it becomes a Big Ball
> of Mud, because then every single port (including
> yet-to-be-contributed ones) have to be adjusted.  I.e., it becomes
> more of a maintenance burden that if we still accessed this field as a
> macro, like we do with DECLs, TREEs, RTXs, etc.

What did you have in mind?  If we simply split or rearrange the
structure later on, I'd have thought the back-end changes would be
largely automatic.

Richard