Re: [PATCH] Introduce abi_word_mode

[Andreas Krebbel <Andreas dot Krebbel at de dot ibm dot com>]

Hello,

> I think you are mixing together several different concepts, observing
> that on the S/390 they all have the same size, and calling that size
> the ABI word mode.  It's not obvious to me that there is any relation
> between the different concepts you want to address.
>
> It's clear that gcc uses word_mode too often.  word_mode is supposed
> to be the size of a general purpose register.  Using that for things
> like the return mode of the compare libcall is a good guess, but that
> is all it is: a guess.  (Using TYPE_MODE (integer_type_node) would
> also be a good guess.)

My hope is that replacing it with abi_word_mode makes it a better guess.
The mode of the return value of a function is coupled to the ABI. word_mode
may change independently from the ABI. So I think a mode defined to be fix
by the ABI would be better here.

> Similarly, word_mode is a good guess for allocate_stack.  But since it
> is not always right, we have STACK_SIZE_MODE.

The mode to be used here is not ABI-relevant and therefore shouldn't stay
abi_word_mode in the future. The only reason I've used abi_word_mode is that
I tried to make this change a nop on all architectures not defining
UNITS_PER_ABI_WORD while making it correct for RS6000 and S/390 as well. 
I probably should have marked this with a fixme.

As I wrote in my previous mail I think that Pmode would be the
best choice. We are looking here for the correct mode for something
to be added to the stack pointer. Since the stack pointer is a Pmode value
I would consider it best to have the other operand in the same mode.
In case an architecture has to do something special or has to convert the
modes in order to be able to emit an ADD it should do this in the
allocate_stack expander - right?!
So I don't see a real need for the STACK_SIZE_MODE macro. The only user
(the power back-end) defines STACK_SIZE_MODE when it needs word_mode to be
different from Pmode. To me this looks more like a word_mode vs. Pmode issue
than word_mode vs. abi_word_mode.


> But despite the fact that word_mode is a good guess for both the
> return mode of the compare libcall and for the allocate_stack mode, I
> don't see any relationship between those two things.  There is no
> reason to assume that a single mode which is not word_mode will be
> correct for both.  So I don't see any obvious reason why we should
> remove STACK_SIZE_MODE in favor of abi_word_mode.  To me it makes more
> sense to introduce COMPARE_LIBCALL_MODE (In the target structure, of
> course).

Why not use abi_word_mode here? Since we are talking about the mode of return
value of a function call I would say this is clearly ABI-relevant and is
what abi_word_mode is made for.

I think the abi_word_mode is a good idea and would prefer it to
adding a set of target macros which seem to be unrelated to each other
at first glance. As you already pointed out word_mode is maybe used too often
in the middle-end and unfortunately it is also used where it shines trough
to external interfaces (e.g. debug info, exception handling etc.).
Defining abi_word_mode appears to be a good solution to me for decoupling the abi
interface from word_mode. Please consider my patch only a first try. I've
expected/hoped to start a discussion about where it makes sense to use 
abi_word_mode and where not.

> In particular, you neglected to write any documentation for
> abi_word_mode, and I think you would have a hard time writing that
> documentation.

Ok. I've omitted the documentation part in this first version since as you say it
is a bit tricky to document this properly. I'll think about something useful.


> __builtin_extend_pointer appears to be undocumented and I have no
> immediate idea what it is for.

My understanding was that this builtin provides a conversion routine from
what a front-end considers a pointer mode (ptr_mode) and what a back-end does
(Pmode). But I couldn't find any uses of it.

Bye,

-Andreas-