s390 port

[Paul Edwards]

We have fait accompli now:

https://gcc.gnu.org/pipermail/gcc/2021-September/237456.html

Simply switching off optimization made the negative
indexes go away, allowing more than 2 GiB to be
addressed in standard z/Arch, with "-m31".

The above request is to add "-m32" as an alias for
"-m31", but I would like to add as a request for it to
work with optimization on.

BFN. Paul.




-----Original Message----- 
From: Paul Edwards
Sent: Friday, September 3, 2021 11:12 PM
To: Jakub Jelinek
Cc: Ulrich Weigand ; gcc@gcc.gnu.org ; Ulrich Weigand
Subject: Re: s390 port

>> > This is not in one single place, but spread throughout the
>> > compiler, both common code and back-end.  I do not think it will
>> > be possible to get the compiler to generate correct code if
>> > you do not specify the address size correctly.

>> 1. Is there any way to put a constraint on index
>> registers, to say that a particular machine can
>> only index in the range of –512 to +512 or some
>> other arbitrary set? If so, I can do 0 to 2 GiB.

>> 2. Is there a way of saying a machine doesn’t
>> support indexing at all?

> There is a way to do that, but it isn't about changing a single or a 
> couple
> of spots, one needs to change a lot of *.md patterns, a lot of macros,
> target hooks and as Ulrich said, most important is to use the right Pmode
> which can differ from ptr_mode provided one e.g. defines ptr_extend 
> pattern
> etc.

Pardon? All that is required just to put a constraint
on an index register? If a range of a machine is
limited to -512 to +512, it shouldn't be necessary
to change md patterns etc etc.

> Just look at the amount of work needed for the x32 or aarch64 ilp32 
> support,

That's different. That's because Intel stuffed up.
IBM didn't. IBM came within an ace of a perfect
architecture. It's as if Intel had created an x32
instead of an 80386 in 1986.

IBM got it almost right in the 1960s.

> and not just work spent one time on adding that support, but the 
> continuous
> amount of work on maintaining it.  The initial work is certainly a few
> weeks if not months of work,

I've been trying to figure out how to lift the 31-bit
restriction on mainframes since around 1987.

If I have to pay someone for 2 month of work, at
this stage, I'm willing to do that, but:

1. I would like it done on GCC 3.2.3 plus maybe
GCC 3.4.6.

2. How much will it cost in US$?

> then there needs to be somebody who regularly
> tests gcc trunk and branches in such configuration so that it doesn't
> bitrot, and not just that but somebody who actually fixes bugs in it.

I'll take responsibility for giving the GCC 3.X.X
releases the TLC they deserve. And I'll encourage
my daughter to maintain them after I've kicked
the bucket.

> If something doesn't fit into 2GB of address space,
> isn't it likely it won't fit into 4GB of address space
> in a year or two?

Nope. 2 GiB is already a shitload of memory. It only
takes something like 23 MB for GCC 3.2.3 to recompile
itself, and I think 60 MB for GCC 3.4.6 to recompile
itself. That's the heaviest real workload I do. A 4 GiB
limitation instead of 2 GiB makes it just that much
less likely I'll ever hit a real limit.

Someone told me that the only non-scientific application
they knew of that came close to hitting the 2 GiB limit
was IBM's C compiler. I doubt that IBM's C compiler
technology is evolving at such a rate that it only takes
1-2 years for them to subsequently hit 4 GiB. Quite
apart from the fact that I don't really trust that even
IBM C is hitting a 2 GiB limit for what GCC can do in
23 MiB. But it could be true - I'm not familiar with
compiler internals.

BFN. Paul.