From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pl1-x62d.google.com (mail-pl1-x62d.google.com [IPv6:2607:f8b0:4864:20::62d]) by sourceware.org (Postfix) with ESMTPS id E1F82385841A for ; Thu, 30 Sep 2021 00:08:19 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org E1F82385841A Received: by mail-pl1-x62d.google.com with SMTP id x4so2706673pln.5 for ; Wed, 29 Sep 2021 17:08:19 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:from:to:cc:subject:date:mime-version :content-transfer-encoding:importance; bh=Cl2kSeY+SvZm4aObIwfGNFrExMNS2e4BaL+uIfq5cuY=; b=4zgizRbIIRr3AwrfslL+6QUjQ84lklYlXAGEeiO1FkUdXehzv8T0ZUmaXn3OWMRWKV u/i89V1jq3l7MlG8bSddX+NbP0vnDPXXOzD+rZsRQeUl6Bs3J4VsuB3Ovevfo9ZVcw3z +VKqg+0CC9Cz8QiD2vzV1x3NTURHbdPByJxre+0unPzADBpm9ZfPHF5WZd0adO2WzA80 a3KlJgCru2J8WNT1zchUCAUvbbvAYLnLI57pHlnllyCpHClnscPJvshqXgknZT+Cf5XI 4mInlM/VC/EdQpUGk5rrm8ugaN/+cX7W56GfaHKcPZgZz1D7HS1A48rYA5Qaq3ZMx097 MdQA== X-Gm-Message-State: AOAM531jpewzo1Bu2dhpz0LG8wxiGgyqD4U8+8p9Ip73dQR/kCTelhTR DrX7M8sN4V/AvdFNUXQd7FQ= X-Google-Smtp-Source: ABdhPJzdhH6u775wAXCZF7vm+RgZ9honEf59cpUi/YSFVuNvSvJRzjOtjjFVXh62RRCf3WHryeJHOg== X-Received: by 2002:a17:903:11c9:b0:13b:9a01:aa27 with SMTP id q9-20020a17090311c900b0013b9a01aa27mr1373786plh.46.1632960499007; Wed, 29 Sep 2021 17:08:19 -0700 (PDT) Received: from DESKTOP0OKG1VA ([202.169.113.201]) by smtp.gmail.com with ESMTPSA id 139sm810788pfz.35.2021.09.29.17.08.16 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 29 Sep 2021 17:08:18 -0700 (PDT) Message-ID: <1D956715852E42F382565AF696D3D005@DESKTOP0OKG1VA> From: "Paul Edwards" To: "Jakub Jelinek" Cc: "Ulrich Weigand" , , "Ulrich Weigand" Subject: Re: s390 port Date: Thu, 30 Sep 2021 10:08:14 +1000 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=response Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 16.4.3528.331 X-MimeOLE: Produced By Microsoft MimeOLE V16.4.3528.331 X-Spam-Status: No, score=-1.6 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, 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 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:08:21 -0000 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.