From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 81434 invoked by alias); 8 Aug 2018 13:31:22 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 81425 invoked by uid 89); 8 Aug 2018 13:31:21 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-2.8 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 spammy=interaction X-HELO: mx0a-001b2d01.pphosted.com Received: from mx0b-001b2d01.pphosted.com (HELO mx0a-001b2d01.pphosted.com) (148.163.158.5) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 08 Aug 2018 13:31:20 +0000 Received: from pps.filterd (m0098419.ppops.net [127.0.0.1]) by mx0b-001b2d01.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w78DSmBO123077 for ; Wed, 8 Aug 2018 09:31:18 -0400 Received: from e06smtp07.uk.ibm.com (e06smtp07.uk.ibm.com [195.75.94.103]) by mx0b-001b2d01.pphosted.com with ESMTP id 2kr0krtgxs-1 (version=TLSv1.2 cipher=AES256-GCM-SHA384 bits=256 verify=NOT) for ; Wed, 08 Aug 2018 09:31:17 -0400 Received: from localhost by e06smtp07.uk.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Wed, 8 Aug 2018 14:31:15 +0100 Received: from b06cxnps4075.portsmouth.uk.ibm.com (9.149.109.197) by e06smtp07.uk.ibm.com (192.168.101.137) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; (version=TLSv1/SSLv3 cipher=AES256-GCM-SHA384 bits=256/256) Wed, 8 Aug 2018 14:31:13 +0100 Received: from d06av25.portsmouth.uk.ibm.com (d06av25.portsmouth.uk.ibm.com [9.149.105.61]) by b06cxnps4075.portsmouth.uk.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id w78DVBrB21168374 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Wed, 8 Aug 2018 13:31:11 GMT Received: from d06av25.portsmouth.uk.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id C256F11C04A; Wed, 8 Aug 2018 16:31:18 +0100 (BST) Received: from d06av25.portsmouth.uk.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id B013A11C054; Wed, 8 Aug 2018 16:31:18 +0100 (BST) Received: from oc3748833570.ibm.com (unknown [9.152.213.80]) by d06av25.portsmouth.uk.ibm.com (Postfix) with ESMTP; Wed, 8 Aug 2018 16:31:18 +0100 (BST) Received: by oc3748833570.ibm.com (Postfix, from userid 1000) id 6FE8ED801FB; Wed, 8 Aug 2018 15:31:11 +0200 (CEST) Subject: Re: [PATCH 2/2] S/390: Remove TARGET_CPU_ZARCH To: iii@linux.ibm.com (Ilya Leoshkevich) Date: Wed, 08 Aug 2018 13:31:00 -0000 From: "Ulrich Weigand" Cc: gcc-patches@gcc.gnu.org, krebbel@linux.ibm.com, iii@linux.ibm.com (Ilya Leoshkevich) In-Reply-To: <20180807081336.14654-3-iii@linux.ibm.com> from "Ilya Leoshkevich" at Aug 07, 2018 10:13:36 AM MIME-Version: 1.0 x-cbid: 18080813-0028-0000-0000-000002E7F1EA X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 18080813-0029-0000-0000-000023A0FC95 Message-Id: <20180808133111.6FE8ED801FB@oc3748833570.ibm.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit X-SW-Source: 2018-08/txt/msg00558.txt.bz2 Ilya Leoshkevich wrote: > TARGET_CPU_ZARCH allowed to distinguish between g5/g6 and newer > machines. Since the former are now gone, we can assume that > TARGET_CPU_ZARCH is always true. As a side-effect, branch splitting > is now completely gone. Some parts of literal pool splitting are > also gone, but it's still there: we need to support it because > floating point and vector instructions still cannot use relative > addressing. Great to see this finally go! B.t.w. the literal pool handling can be simplified further now. The current code was made complicated due to the potential of interaction between branch splitting and literal pool splitting, see the long comment: However, the two problems are interdependent: splitting the literal pool can move a branch further away from its target, causing the 64K limit to overflow, and on the other hand, replacing a PC-relative branch by an absolute branch means we need to put the branch target address into the literal pool, possibly causing it to overflow. So, we loop trying to fix up both problems until we manage to satisfy both conditions at the same time. [...] Since branch splitting is gone, this whole logic is superfluous; the loop will never execute more than once. (It may not be necessary any longer to split the logic into the various chunkify_start/finish routines either ...) Bye, Ulrich -- Dr. Ulrich Weigand GNU/Linux compilers and toolchain Ulrich.Weigand@de.ibm.com