From patchwork Wed Aug 15 10:50:39 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Ilya Leoshkevich X-Patchwork-Id: 957845 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Authentication-Results: ozlabs.org; spf=pass (mailfrom) smtp.mailfrom=gcc.gnu.org (client-ip=209.132.180.131; helo=sourceware.org; envelope-from=gcc-patches-return-483692-incoming=patchwork.ozlabs.org@gcc.gnu.org; receiver=) Authentication-Results: ozlabs.org; dmarc=none (p=none dis=none) header.from=linux.ibm.com Authentication-Results: ozlabs.org; dkim=pass (1024-bit key; unprotected) header.d=gcc.gnu.org header.i=@gcc.gnu.org header.b="HdhNu6CM"; dkim-atps=neutral Received: from sourceware.org (server1.sourceware.org [209.132.180.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ozlabs.org (Postfix) with ESMTPS id 41r5qB3F8Tz9sBZ for ; Wed, 15 Aug 2018 20:51:00 +1000 (AEST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gcc.gnu.org; h=list-id :list-unsubscribe:list-archive:list-post:list-help:sender:from :to:cc:subject:date:message-id; q=dns; s=default; b=s2es5suOhOV2 CQoL/sgEYQkISJtmHdZokSRbgqeH5i9hsI8ACAJsA6aKTYgMlV2NRwg3WZiZ99e1 j6CwWYjEwkIPbu7JQEUFpsXbGAbbhL87sitvSnigX3x6QooZqpdiUkP9JngHvbFJ 4Ko0Pk38xrkzx8DC28IzqypW5JPkFLM= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=gcc.gnu.org; h=list-id :list-unsubscribe:list-archive:list-post:list-help:sender:from :to:cc:subject:date:message-id; s=default; bh=6DWachznjg3XSKg5Ce QECBTugkA=; b=HdhNu6CMeiW4CMEQBV/7JW0czjBCtZUdsw5b2E4Q4OzaM+sy13 McjED1XJKRi+SCLPYT64QuY5rxIhqJfOWit0GNhy5vudmSQM8ha4PWtm7KrE2Vgd INNo3nVsjD8FXcBXiSWMOQq+qAW4dWoKOTUzzccfFxNoezAwKlRAhMURc= Received: (qmail 113509 invoked by alias); 15 Aug 2018 10:50:54 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Delivered-To: mailing list gcc-patches@gcc.gnu.org Received: (qmail 113500 invoked by uid 89); 15 Aug 2018 10:50:53 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-27.2 required=5.0 tests=AWL, BAYES_00, GIT_PATCH_0, GIT_PATCH_1, GIT_PATCH_2, GIT_PATCH_3, RCVD_IN_DNSWL_LOW, SPF_PASS autolearn=ham version=3.3.2 spammy= 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, 15 Aug 2018 10:50:51 +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 w7FAhabD106371 for ; Wed, 15 Aug 2018 06:50:50 -0400 Received: from e06smtp01.uk.ibm.com (e06smtp01.uk.ibm.com [195.75.94.97]) by mx0b-001b2d01.pphosted.com with ESMTP id 2kvesthcjg-1 (version=TLSv1.2 cipher=AES256-GCM-SHA384 bits=256 verify=NOT) for ; Wed, 15 Aug 2018 06:50:49 -0400 Received: from localhost by e06smtp01.uk.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Wed, 15 Aug 2018 11:50:48 +0100 Received: from b06cxnps3075.portsmouth.uk.ibm.com (9.149.109.195) by e06smtp01.uk.ibm.com (192.168.101.131) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; (version=TLSv1/SSLv3 cipher=AES256-GCM-SHA384 bits=256/256) Wed, 15 Aug 2018 11:50:45 +0100 Received: from d06av26.portsmouth.uk.ibm.com (d06av26.portsmouth.uk.ibm.com [9.149.105.62]) by b06cxnps3075.portsmouth.uk.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id w7FAoijW37355610 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Wed, 15 Aug 2018 10:50:44 GMT Received: from d06av26.portsmouth.uk.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id D548FAE051; Wed, 15 Aug 2018 13:50:29 +0100 (BST) Received: from d06av26.portsmouth.uk.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id A6222AE04D; Wed, 15 Aug 2018 13:50:29 +0100 (BST) Received: from white.boeblingen.de.ibm.com (unknown [9.152.98.63]) by d06av26.portsmouth.uk.ibm.com (Postfix) with ESMTP; Wed, 15 Aug 2018 13:50:29 +0100 (BST) From: Ilya Leoshkevich To: gcc-patches@gcc.gnu.org Cc: krebbel@linux.ibm.com, Ilya Leoshkevich Subject: [PATCH v2] S/390: Remove literal pool chunkification loop Date: Wed, 15 Aug 2018 12:50:39 +0200 x-cbid: 18081510-4275-0000-0000-000002AA1C8A X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 18081510-4276-0000-0000-000037B33D63 Message-Id: <20180815105039.75001-1-iii@linux.ibm.com> Since there is no branch splitting anymore, the loop is no longer necessary: pool chunkification can be done in one step. gcc/ChangeLog: 2018-08-13 Ilya Leoshkevich * config/s390/s390.c (s390_reorg): remove loop --- gcc/config/s390/s390.c | 68 ++++++++++-------------------------------- 1 file changed, 16 insertions(+), 52 deletions(-) diff --git a/gcc/config/s390/s390.c b/gcc/config/s390/s390.c index 50bd316abfd..3e183ddb55c 100644 --- a/gcc/config/s390/s390.c +++ b/gcc/config/s390/s390.c @@ -13902,7 +13902,7 @@ s390_adjust_loops () static void s390_reorg (void) { - bool pool_overflow = false; + struct constant_pool *pool; rtx_insn *insn; int hw_before, hw_after; @@ -13914,62 +13914,26 @@ s390_reorg (void) split_all_insns_noflow (); /* Install the main literal pool and the associated base - register load insns. - - In addition, there are two problematic situations we need - to correct: - - - the literal pool might be > 4096 bytes in size, so that - some of its elements cannot be directly accessed + register load insns. The literal pool might be > 4096 bytes in + size, so that some of its elements cannot be directly accessed. - - a branch target might be > 64K away from the branch, so that - it is not possible to use a PC-relative instruction. - - To fix those, we split the single literal pool into multiple + To fix this, we split the single literal pool into multiple pool chunks, reloading the pool base register at various points throughout the function to ensure it always points to - the pool chunk the following code expects, and / or replace - PC-relative branches by absolute branches. - - 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. + the pool chunk the following code expects. */ - So, we loop trying to fix up both problems until we manage - to satisfy both conditions at the same time. Note that the - loop is guaranteed to terminate as every pass of the loop - strictly decreases the total number of PC-relative branches - in the function. (This is not completely true as there - might be branch-over-pool insns introduced by chunkify_start. - Those never need to be split however.) */ - - for (;;) + /* Collect the literal pool. */ + pool = s390_mainpool_start (); + if (pool) { - struct constant_pool *pool = NULL; - - /* Collect the literal pool. */ - if (!pool_overflow) - { - pool = s390_mainpool_start (); - if (!pool) - pool_overflow = true; - } - - /* If literal pool overflowed, start to chunkify it. */ - if (pool_overflow) - pool = s390_chunkify_start (); - - /* If we made it up to here, both conditions are satisfied. - Finish up literal pool related changes. */ - if (pool_overflow) - s390_chunkify_finish (pool); - else - s390_mainpool_finish (pool); - - break; + /* Finish up literal pool related changes. */ + s390_mainpool_finish (pool); + } + else + { + /* If literal pool overflowed, chunkify it. */ + pool = s390_chunkify_start (); + s390_chunkify_finish (pool); } /* Generate out-of-pool execute target insns. */