From patchwork Thu Sep 22 04:52:59 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Senthil Kumar Selvaraj X-Patchwork-Id: 673127 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org 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 3sfkg60yX1z9s36 for ; Thu, 22 Sep 2016 14:54:23 +1000 (AEST) Authentication-Results: ozlabs.org; dkim=pass (1024-bit key; unprotected) header.d=gcc.gnu.org header.i=@gcc.gnu.org header.b=Id6Lp+q5; dkim-atps=neutral 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:mime-version:content-type; q=dns; s=default; b=uycI0mic39HVFLAiE0MUtDoXSgMixcKwe8PPnwPWkiXTt8dovZ H2zJTiGg3puqp4UpHqcCb3EyBn5NX2fGY6NxyiAnycAI+AFWqyB/OKLENAhiI7M1 yRsIvHksV+dminkhpIQejoYra1hg00JUtDLE5JQD/Q+e9d3XgOaZb1aUk= 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:mime-version:content-type; s= default; bh=Nf1pWVtSRT95dQ7p7qorG190DOM=; b=Id6Lp+q55GW094z6dkAU nHUi/uwoS23dDCWFv1znTmBxoZe0xWb+GSI5X+E2qRHfaysGt/FHnhEGYAiKHGCp rcsXq0h4XQMxMuxVgpNCJWmUcmI5UKVGCU/t5g2EjvCEjWvnF5kv6EirlAft8M5q 3aOmHD5DhS/xq6XwziJd2QI= Received: (qmail 42094 invoked by alias); 22 Sep 2016 04:54:14 -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 42085 invoked by uid 89); 22 Sep 2016 04:54:13 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-5.0 required=5.0 tests=BAYES_00, RP_MATCHES_RCVD, SPF_PASS autolearn=ham version=3.3.2 spammy=incurred, UD:lists.nongnu.org, sk:lists.n, multiply X-HELO: eusmtp01.atmel.com Received: from eusmtp01.atmel.com (HELO eusmtp01.atmel.com) (212.144.249.242) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 22 Sep 2016 04:54:03 +0000 Received: from HNOCHT02.corp.atmel.com (10.145.133.41) by eusmtp01.atmel.com (10.145.145.30) with Microsoft SMTP Server (TLS) id 14.3.235.1; Thu, 22 Sep 2016 06:53:54 +0200 Received: from jaguar.atmel.com (10.145.133.18) by HNOCHT02.corp.atmel.com (10.145.133.41) with Microsoft SMTP Server (TLS) id 14.3.235.1; Thu, 22 Sep 2016 06:53:57 +0200 User-agent: mu4e 0.9.17; emacs 24.5.1 From: Senthil Kumar Selvaraj To: "gcc-patches@gcc.gnu.org" CC: Denis Chertykov Subject: [Patch, avr] Provide correct LD offset bound in avr_address_cost Date: Thu, 22 Sep 2016 10:22:59 +0530 Message-ID: <87h998ilhw.fsf@atmel.com> MIME-Version: 1.0 X-IsSubscribed: yes Hi, This patch fixes cost computation in avr_address_cost - instead of the hardcoded 61, it uses the already existing MAX_LD_OFFSET(mode) macro. This showed up when investigating a code size regression in the ivopts pass. That pass computes address_cost with and without an offset to decide on the right induction variable candidate(s). The legitimate address target hook returns false for offsets more than 63, so the pass calls the TARGET_ADDRESS_COST hook with 62 as the offset. The hook implementation returns 18, and the ivopts pass concludes that the cost of address with *any* offset is 18, which is not true - the higher cost is incurred only with offsets bigger than MAX_LD_OFFSET. This in turn results in a suboptimal choice of induction variables in the ivopts pass. The patch changes the hardcoded 61 to use the mode specific MAX_LD_OFFSET instead. Regression testing with just that fix showed one additional compilation timeout. That turned out to be the same as https://lists.nongnu.org/archive/html/avr-gcc-list/2014-03/msg00010.html - the middle end takes too much time to decide on the best strategy to multiply DImode values on a 64 bit host. This already causes timeouts for a few builtin-arith-overflow-* tests (see https://gcc.gnu.org/ml/gcc-testresults/2016-09/msg02018.html), so it isn't really related to this fix. Just providing a cost estimate for DImode mul fixes the timeout though, so the patch does that by scaling SImode costs by 2 for DImode muls. With both changes in, there are no regressions, and the builtin-arith-overflow-* tests now PASS and don't timeout. Ok to commit to trunk and backport to 5.x? Regards Senthil gcc/ChangeLog: 2016-09-21 Senthil Kumar Selvaraj * config/avr/avr.c (avr_rtx_costs_1): Handle DImode MULT. (avr_address_cost): Replace 61 with MAX_LD_OFFSET(mode). diff --git gcc/config/avr/avr.c gcc/config/avr/avr.c index 148a61d..29f0022 100644 --- gcc/config/avr/avr.c +++ gcc/config/avr/avr.c @@ -10257,6 +10257,7 @@ avr_rtx_costs_1 (rtx x, machine_mode mode, int outer_code ATTRIBUTE_UNUSED, break; case SImode: + case DImode: if (AVR_HAVE_MUL) { if (!speed) @@ -10282,7 +10283,10 @@ avr_rtx_costs_1 (rtx x, machine_mode mode, int outer_code ATTRIBUTE_UNUSED, *total = COSTS_N_INSNS (AVR_HAVE_JMP_CALL ? 5 : 4); } - return true; + if (mode == DImode) + *total *= 2; + + return true; default: return false; @@ -10863,7 +10867,7 @@ avr_address_cost (rtx x, machine_mode mode ATTRIBUTE_UNUSED, && (REG_P (XEXP (x, 0)) || GET_CODE (XEXP (x, 0)) == SUBREG)) { - if (INTVAL (XEXP (x, 1)) >= 61) + if (INTVAL (XEXP (x, 1)) > MAX_LD_OFFSET(mode)) cost = 18; } else if (CONSTANT_ADDRESS_P (x))