This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] Introduce abi_word_mode

Ian Lance Taylor wrote:

> I think that you are making an assumption: that there is a single mode
> which makes sense for a set of disparate uses.  I think that is a
> rather strong assumption, and I think that you need to justify it, and
> you need to justify it in the form of clear and precise documentation.
> Otherwise we are just going to wind up with yet another ill-defined
> concept with no clear guidance on when it should be used.

As I see it, there is one clear definition of abi_word_mode: the mode
to be used for a variable declared with attribute ((mode (word))).

This is clearly a property of the ABI, so if we have two configurations
of GCC that purport to support the same ABI, but need to use differing
definitions of word_mode internally because they use differently-sized
general purpose registers, then we need a new target-defined mode that
the middle-end can use to implement attribute ((mode (word))).

This mode is what Andreas has been calling abi_word_mode.  (I guess we
can debate the name, but that's a separate discussion.)

Now, if we accept that basic definition, a number of uses of word_mode
in the middle-end naturally fall in the abi_word_mode category: every
place where the middle-end uses word_mode to define a data structure
that is externally visible and accessed via an attribute ((mode (word)))
declaration needs to be changed to abi_word_mode too.  This is the case
in particular for the EH data structures, as I understand.

Then, there may be a couple of uses of word_mode that are simply
erroneous and should be fixed (e.g. the errno case, or most likely
the STACK_SIZE_MODE case).

Finally, I agree that there are a number of remaining cases (like the
libcall return mode) that do not naturally fall into the abi_word_mode
case -- then again, maybe this particular case does if we consider
those libcall functions to be declared as having return type
int attribute ((mode (word))) ...  :-)

Having a separate target definition for such uses may be the best
solution -- on the other hand, I'm a bit sceptical about adding lots
of new target macros without having evidence that targets actually
want to define them differently.


  Dr. Ulrich Weigand
  Linux on zSeries Development

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]