This is the mail archive of the
mailing list for the GCC project.
Re: [PATCH] Introduce abi_word_mode
- From: Ian Lance Taylor <iant at google dot com>
- To: "Ulrich Weigand" <uweigand at de dot ibm dot com>
- Cc: Andreas dot Krebbel at de dot ibm dot com (Andreas Krebbel), gcc-patches at gcc dot gnu dot org
- Date: 05 Oct 2006 08:25:36 -0700
- Subject: Re: [PATCH] Introduce abi_word_mode
- References: <200610051245.k95Cj1qT010745@d12av02.megacenter.de.ibm.com>
"Ulrich Weigand" <firstname.lastname@example.org> writes:
> > 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))).
That makes sense to me. Thanks. I do need to mention that you are
talking about an unusual case. You want to be able to link together
different code compiled with different register sizes but using the
> 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.
Yes, this would apply to the EH data structures and it would apply to
the shift and comparison libcalls.
For what it's worth, the EH data structures already use #ifdefs to
pick the right size for a particular target--see unwind-generic.h.
TARGET_EH_RETURN_FILTER_MODE exists to make the definition of
_Unwind_Word match the way the value is used in except.c. Something
like this will be required if you want to compile new code that uses a
different word size and wants to link against an existing libgcc_eh.so.
I'm willing to look at a patch which fixes those cases only.
> 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).
Yes, and to be clear, they should not change to abi_word_mode.
> 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))) ... :-)
Actually, the libcall return mode does get covered by your definition
of abi_word_mode; see the use of word_type in libgcc2.c.
> 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.
I agree that we should only add new target macros when necessary.