From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wr1-x42f.google.com (mail-wr1-x42f.google.com [IPv6:2a00:1450:4864:20::42f]) by sourceware.org (Postfix) with ESMTPS id 7B2C43858C39 for ; Thu, 30 Sep 2021 00:59:54 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 7B2C43858C39 Received: by mail-wr1-x42f.google.com with SMTP id d6so7108149wrc.11 for ; Wed, 29 Sep 2021 17:59:54 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=4+xdGn4rQLLhbi1jWM0sxDkepmjsfObEOpC3Jo1ug/g=; b=cF3iSFMQ617vZB8IkdY6XGZXkGRoDC3g+wy/lRy9OZGfhrvYT77NVDM1Dx7d6ZZKV7 FyO+gU+nbnWzbj411LNN6FEbQRmWcvA0muJZOAFf4vW6k7KZjdXERWqmHQo0f9gK+aoj SpZfDWps0ZKU67dmAQ++2DKfcxl1YuVKa8MSXpo7A0bt1KzrKFTsEkAmsA8qu6YAWiiQ 7Ezqf5UFvAiWrK9nM5I5fgvy+Tqz+fvFe4Bj4xcjN62zZ4lrhzg2ynwee4KpffF5ESS/ Lw0lsWxhyXIa1DQ9y5W6b1W3wI++Fx5FDgaJTWas4eFDxBfQnHAsHdLj9/XZ/O1PD8pc OBlg== X-Gm-Message-State: AOAM533+WlSystxwLb4my88qTpClT5QUHDaCZTpVfkgHXaZLyGGStL6i rE1IZUK8lCyWqRqcOXgjbkeYg139fbWSihNA/keiaS1RYg1sBw== X-Google-Smtp-Source: ABdhPJyThhgktO3RWpzLhO3iXanBF8lq22sCKoO8pD5FIz2t4+WKOmq0AP+CG4q3gqvsvPl5FIrQ70GBWpXje5RN7OM= X-Received: by 2002:a05:6000:104e:: with SMTP id c14mr3092620wrx.130.1632963592939; Wed, 29 Sep 2021 17:59:52 -0700 (PDT) MIME-Version: 1.0 References: <1D956715852E42F382565AF696D3D005@DESKTOP0OKG1VA> In-Reply-To: <1D956715852E42F382565AF696D3D005@DESKTOP0OKG1VA> From: Joe Monk Date: Wed, 29 Sep 2021 19:59:41 -0500 Message-ID: Subject: Re: s390 port To: gcc@gcc.gnu.org X-Spam-Status: No, score=-1.1 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_ENVFROM_END_DIGIT, FREEMAIL_FROM, HTML_MESSAGE, KAM_SHORT, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: gcc@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Sep 2021 00:59:56 -0000 "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 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 =E2=80=93512 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=E2=80=99t > >> 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 Pmo= de > > 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. > >