Re: [PATCH] Introduce abi_word_mode

["Ulrich Weigand" <uweigand at de dot ibm dot com>]

Richard Sandiford wrote:

> Sorry to hammer on about this -- I'm probably just being dense -- but
> defining the ABI word mode to be "the mode of attribute ((mode (word)))"
> seems inherently cyclic.  attribute ((mode (...))) is just a way of
> exposing gcc's internal modes to users.  The documentation of the
> attribute doesn't seem to anchor it to externals much:
> 
>     You may also specify a mode of @samp{byte} or @samp{__byte__} to
>     indicate the mode corresponding to a one-byte integer, @samp{word} or
>     @samp{__word__} for the mode of a one-word integer, [...]
> 
> If we have two different concepts of "word" in play, this documentation
> doesn't really help either.

Well, at the core the situation is this:

The GCC middle end has the notion of a "word", which is somewhat vaguely
defined as "the natural mode of a general-purpose register".  Its main
technical distinction, as I see it, is that it defines the behaviour of
SUBREG -- multi-word SUBREGs are just fundamentally different from 
subword SUBREGs.  (Of course, this is not just an arbitrary GCC wart, 
but reflects the fact that parts of a register are typically not directly
addressable.)  As a back-end writer, this leaves me no choice how to
define UNITS_PER_WORD.

On the other hand, for better or worse, GCC has made this internal detail
available at a source code level via attribute ((mode (word))).  This
makes the choice of word_mode relevant at an ABI level.  Again, if I 
want to implement a GCC configuration that adheres to a pre-existing ABI
(including its attribute ((mode (word)))), I have no choice how to
define UNITS_PER_WORD.

Unfortunately, in the situation we're in, those two conditions are in
conflict: we want to implement a configuration of the s390 back-end
that makes full use of 64-bit registers, so UNITS_PER_WORD *has* to
be 8 or else everything related to SUBREGs breaks.  On the other hand,
this configuration has to support the pre-existing 32-bit s390 ABI,
which requires that attribute ((mode (word))) defines a 4-byte data
type.

To resolve the conflict, we're proposing to break the hard coupling
between attribute ((mode (word))) and word_mode.  This recognizes 
that attribute ((mode (word))) is ABI-relevant, and thus should be
settable independently of GCC internals, just like all other ABI 
facets are.  This new, independent setting is just the proposed
"ABI word mode".

Now, in general the "ABI word mode" will still default to the word
mode of the platform.  Only in rare situations, like where we want
to "emulate" an ABI on a target with different register size, will
the two differ.  So you could define the "ABI word mode" as "the
natural mode of a general-purpose register on the main platform
that implements this ABI" or so.

Does this help?  I'd certainly appreciate suggestions how to
formulate this is a clearer way ...

Bye,
Ulrich

-- 
  Dr. Ulrich Weigand
  Linux on zSeries Development
  Ulrich.Weigand@de.ibm.com