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

"Ulrich Weigand" <> 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
same ABI.

> 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

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.


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