From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [216.205.24.124]) by sourceware.org (Postfix) with ESMTP id D43FD385840F for ; Fri, 3 Sep 2021 12:53:16 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org D43FD385840F Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-371-PufxXXBaNJ-q5BGuVX_4Uw-1; Fri, 03 Sep 2021 08:53:13 -0400 X-MC-Unique: PufxXXBaNJ-q5BGuVX_4Uw-1 Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 426C6501EE; Fri, 3 Sep 2021 12:53:12 +0000 (UTC) Received: from tucnak.zalov.cz (unknown [10.39.192.2]) by smtp.corp.redhat.com (Postfix) with ESMTPS id ADFD26F7E3; Fri, 3 Sep 2021 12:53:11 +0000 (UTC) Received: from tucnak.zalov.cz (localhost [127.0.0.1]) by tucnak.zalov.cz (8.16.1/8.16.1) with ESMTPS id 183Cr9sS4088287 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Fri, 3 Sep 2021 14:53:09 +0200 Received: (from jakub@localhost) by tucnak.zalov.cz (8.16.1/8.16.1/Submit) id 183Cr9NN4088286; Fri, 3 Sep 2021 14:53:09 +0200 Date: Fri, 3 Sep 2021 14:53:09 +0200 From: Jakub Jelinek To: Paul Edwards Cc: Ulrich Weigand , gcc@gcc.gnu.org, Ulrich Weigand Subject: Re: s390 port Message-ID: <20210903125309.GB920497@tucnak> Reply-To: Jakub Jelinek References: <18CA5177BA304CEAB8464FD24D0DF307@DESKTOP0OKG1VA> <2D0FCE9CBE22470A9361F94E221775BA@DESKTOP0OKG1VA> <0A22522993EB4341AFA02779328F247D@DESKTOP0OKG1VA> MIME-Version: 1.0 In-Reply-To: <0A22522993EB4341AFA02779328F247D@DESKTOP0OKG1VA> X-Scanned-By: MIMEDefang 2.79 on 10.5.11.11 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-5.8 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, RCVD_IN_DNSWL_LOW, RCVD_IN_MSPIKE_H2, SPF_HELO_NONE, SPF_NONE, 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 12:53:17 -0000 On Fri, Sep 03, 2021 at 10:38:36PM +1000, Paul Edwards via Gcc wrote: > > 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. Just look at the amount of work needed for the x32 or aarch64 ilp32 support, 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, 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. 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? Jakub