From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pf1-x42a.google.com (mail-pf1-x42a.google.com [IPv6:2607:f8b0:4864:20::42a]) by sourceware.org (Postfix) with ESMTPS id 17FCE385840F for ; Fri, 3 Sep 2021 13:12:51 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 17FCE385840F Received: by mail-pf1-x42a.google.com with SMTP id y17so4250015pfl.13 for ; Fri, 03 Sep 2021 06:12:51 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:message-id:from:to:cc:references:in-reply-to :subject:date:mime-version:content-transfer-encoding:importance; bh=8yEB+nDHJi9F6Lv2B4PPpFsexQdCIqcaHR+f0+0tveg=; b=IBdGtaKOJmP0UYYE5f++bVJInD3wo173WqZh21z5e4AveAtP0gIBw/Vd1tWQ7B9MBJ 5ZRdWg/NFsKrdUBNPZs2LKbgHlNzm/Sgw+f/DNSpcWIV/qXqSwpqD/4/hJZlIH3u9Lx9 DLgPbA6aSJ3Y4rfXqu4a356K9zesvcURsNv6guf2s0EdebVudNgYo8BdhI5J7PIvdwJg DzfjZBuQd026gCZE05FuuFHXQjQvkDvF/qACtu/tt+ZGbzvfubvdIPQGn/VchXWRz5G5 iFyv6ld+YgqJxWtnknzexRXO7U3uk+L/etkPVYk/QkpUy5jaDR18ubNYvaDnwaApjnWx OiGg== X-Gm-Message-State: AOAM532nnnScMHgdtdaSetBs8GXCb6dSd0k9GiLu0wIIVbkoICp6Dbj0 gXBiRhoQ6Oo7MBP3A3ptyGw= X-Google-Smtp-Source: ABdhPJxfhM9KP5FUz+eeBmy+k+lodWs2mz4q26kSnRqfEmwM8/u6vg3s5jXa1qAlaYJnZV6oesBZDA== X-Received: by 2002:a63:27c1:: with SMTP id n184mr3555726pgn.214.1630674769904; Fri, 03 Sep 2021 06:12:49 -0700 (PDT) Received: from DESKTOP0OKG1VA ([202.169.113.201]) by smtp.gmail.com with ESMTPSA id s3sm5325231pfd.188.2021.09.03.06.12.47 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 03 Sep 2021 06:12:49 -0700 (PDT) Message-ID: From: "Paul Edwards" To: "Jakub Jelinek" Cc: "Ulrich Weigand" , , "Ulrich Weigand" References: <18CA5177BA304CEAB8464FD24D0DF307@DESKTOP0OKG1VA> <2D0FCE9CBE22470A9361F94E221775BA@DESKTOP0OKG1VA> <0A22522993EB4341AFA02779328F247D@DESKTOP0OKG1VA> <20210903125309.GB920497@tucnak> In-Reply-To: <20210903125309.GB920497@tucnak> Subject: Re: s390 port Date: Fri, 3 Sep 2021 23:12:44 +1000 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original 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.3 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, STOX_REPLY_TYPE, 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: Fri, 03 Sep 2021 13:12:54 -0000 >> > 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.