[PATCH] Introduce abi_word_mode

[Ulrich Weigand]

Richard Sandiford wrote:

> > And this is exactly what we want to achieve -- provide a configuration
> > of GCC for s390 that exploits the capabilities of 64-bit machines,
> > while keeping link compatibility with the 31-bit ABI.
> 
> ...I'm not disputing that's a good thing.  I'm just disputing that
> word(mode) is something you should use in an interface that has to be
> link-compatible with pure 31-bit code.  Both meanings under discussion
> have an ABI meaning, and if we have to keep the thing at all, I think
> the current meaning makes more sense.  It seems like the kind of thing
> that would be useful if you want to exploit the extra capabilities
> you're trying to exploit here.

Well, the way I see it, the user shouldn't even have to think about
some interfaces that are link-compatible with "pure" 31-bit code,
while other may not be -- the mode of operation of GCC I'm envisioning
should *be* "pure 31-bit" as far as link compatibility is concerned.

This is something that should be possible to switch on as a pure
optimization option, without changing any behaviour visibile on
the source code level.  (In fact, since current Linux distributions
on s390 no longer support 31-bit kernels, it should be feasible for
the 31-bit distribution compiler to default to this mode.)

This is why I'm wary of statements that say the user shouldn't
be using this or that GCC feature if they want to be able to
use this mode.


I'm aware that this goal is probably not attainable 100% anyway, 
since e.g. some uses of inline assembly will invariably operate
differently in the 64-bit register 31-bit ABI mode.  Still I'd
like to keep the discrepancies to the absolute minimum possible.


> > If there were a clear understanding that attribute ((mode (word)))
> > may change between configurations even if they otherwise support
> > the same ABI (in the sense of link compatibility), then I guess
> > attribute ((mode (word)) would be a suitable type for strictly
> > local use as you describe above.  But the current user of
> > ((mode (word))), at least in the GCC code base, are not of
> > that type.
> 
> I think there was agreement in principle that gcc itself
> should change though.

Well, I agree that it would be good to do so if possible, I just
don't see how it can be done right now ...

> > Also, I still claim that I don't want to provide a "different"
> > definition that the one we've been providing. I just want to clarify
> > how the -currently vague- definition applies in an area where we
> > hadn't needed to apply it before.
> 
> OK, well we clearly disagree there.

I guess the disagreement comes down to differing user expectations.
In the proposed 64-bit register 31-bit ABI mode *I* would have 
expected as a user that mode(word) gives me SImode -- that's the
size of registers used for parameter passing, stack slots, 
entries in jmp_buf or ucontext_t etc.

I can see the response that, well, the real register size of the
machine is 64-bit.  But this is not really specific to the compiler
options used to build the binary, it is simply a fact caused by
the mode of operation of the hardware.  Even without changing
anything in the compiler, so that it generates a pristine 31-bit
binary that will run on 15 year old machines -- if you run that
binary on a 64-bit machine the "real" register size is 64-bit,
and that could actually be visible to, say, in-line assembly.

I guess what I just don't see is why a compiler option to tell
GCC to make more extensive use of that fact of the hardware for
optimization purposes should suddenly cause user-visible changes
like getting a differently sized mode(word) data type.

Bye,
Ulrich

-- 
  Dr. Ulrich Weigand
  Linux on zSeries Development
  Ulrich.Weigand@de.ibm.com