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