This is the mail archive of the
mailing list for the GCC project.
Re: [PATCH] Introduce abi_word_mode
- From: "Ulrich Weigand" <uweigand at de dot ibm dot com>
- To: iant at google dot com (Ian Lance Taylor)
- Cc: Andreas dot Krebbel at de dot ibm dot com (Andreas Krebbel), gcc-patches at gcc dot gnu dot org
- Date: Thu, 5 Oct 2006 14:45:01 +0200 (CEST)
- Subject: 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