Re: s390 port

[Joe Monk <joemonk64@gmail.com>]

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

Prove it on real hardware, not hercules. Hercules doesnt count.

Joe

On Wed, Sep 29, 2021 at 7:09 PM Paul Edwards via Gcc <gcc@gcc.gnu.org>
wrote:

> 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.
>
>