From patchwork Mon Jun 9 18:52:19 2014 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Uros Bizjak X-Patchwork-Id: 357588 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 2A4271400AB for ; Tue, 10 Jun 2014 04:52:30 +1000 (EST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gcc.gnu.org; h=list-id :list-unsubscribe:list-archive:list-post:list-help:sender :mime-version:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; q=dns; s=default; b=MCESmj7vuhGXeO3bWj LhjfvpcDj5hiMjvZy4bBshSpLinniUz00uyK9TPq2veAX87y6CiFiVQxvIWtk8LK Gq0vr20fpweyxs+8aQQxlQj82TkAp8LXV1NCliU1PToxiJjYqe0b6arqiDRNntzz Mn5MSLbJvndh78cCjwBKQqvvo= 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 :mime-version:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; s=default; bh=UyLBIFBOlW7dhVXZah7y7/qE So4=; b=TlYnrAz1ojKGS4cmwd811T0BRcOBzwO/LoOoJKBMJk7clbZdi8fTD2Hx NQU3lvyb+sIpfLwqMMvpwS+4B+CeXZepIyboCujAxC1wOcrdc2sYuJ7fo+YX6TZP +yFTN/yZg6weZRff8B7JvWgOdbjT5u6usL6j57m0tOzP5f9/u0M= Received: (qmail 24210 invoked by alias); 9 Jun 2014 18:52:24 -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 24198 invoked by uid 89); 9 Jun 2014 18:52:23 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.4 required=5.0 tests=AWL, BAYES_00, FREEMAIL_FROM, RCVD_IN_DNSWL_LOW, SPF_PASS autolearn=ham version=3.3.2 X-HELO: mail-oa0-f51.google.com Received: from mail-oa0-f51.google.com (HELO mail-oa0-f51.google.com) (209.85.219.51) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-SHA encrypted) ESMTPS; Mon, 09 Jun 2014 18:52:21 +0000 Received: by mail-oa0-f51.google.com with SMTP id j17so2792973oag.24 for ; Mon, 09 Jun 2014 11:52:20 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.182.128.202 with SMTP id nq10mr4113747obb.77.1402339940011; Mon, 09 Jun 2014 11:52:20 -0700 (PDT) Received: by 10.182.197.202 with HTTP; Mon, 9 Jun 2014 11:52:19 -0700 (PDT) In-Reply-To: References: Date: Mon, 9 Jun 2014 20:52:19 +0200 Message-ID: Subject: Re: [PATCH, i386]: Correctly handle maximum size of stringop algorithm in decide_alg From: Uros Bizjak To: "gcc-patches@gcc.gnu.org" Cc: Jan Hubicka Ping. On Mon, Jun 2, 2014 at 11:12 PM, Uros Bizjak wrote: > Hello! > > A problem was uncovered by -march=corei7 -mtune=intel -m32 with > i386/memcpy-[23] testcase in decide_alg subroutine [1]. Although the > max size of the transfer was known, the memcpy was not inlined, as > expected by the testcase. > > The core of the problem can be seen in the definition of 32bit > intel_memcpy stringop alg: > > {libcall, {{11, loop, false}, {-1, rep_prefix_4_byte, false}}}, > > Please note that the last algorithm sets its maximum size to -1, > "unlimited". However, in decide_alg, the same number also signals that > no algorithm sets its size, so expected_size is never calculated. In > the loop that sets maximal size for user defined algorithm, it is > assumed that "-1" belongs exclusively to libcall, which is not the > case in the above intel_memcpy definition: > > if (candidate != libcall && candidate && usable) > max = algs->size[i].max; > > When the last non-libcall algorithm sets its maximum to "-1" (aka > "unlimited"), this value fails following test: > > if (max > 1 && (unsigned HOST_WIDE_INT) max >= max_size > > and expected_size is never calculated. > > Attached patch fixes this oversight, so "-1" means unlimited size and > "0" means that size was never set. The patch also considers these two > special values when choosing a maximum size for dynamic check. > > 2014-06-02 Uros Bizjak > > * config/i386/i386.c (decide_alg): Correctly handle maximum size of > stringop algorithm. > > Patch was bootstrapped and regression tested on x86_64-pc-linux-gnu > {,-m32}, also with > RUNTESTFLAGS="--target_board=unix/-march=corei7/-mtune=intel\{,-m32\}", > where it fixes both memcpy failures from [1]. > > [1] https://gcc.gnu.org/ml/gcc-testresults/2014-06/msg00127.html > > Jan, can you please review the patch, to check if the logic is OK? > > Uros. Index: ChangeLog =================================================================== --- ChangeLog (revision 211140) +++ ChangeLog (working copy) @@ -1,3 +1,8 @@ +2014-06-02 Uros Bizjak + + * config/i386/i386.c (decide_alg): Correctly handle maximum size of + stringop algorithm. + 2014-06-02 Marcus Shawcroft * config/aarch64/aarch64.md (set_fpcr): Drop ISB after FPCR write. Index: config/i386/i386.c =================================================================== --- config/i386/i386.c (revision 211140) +++ config/i386/i386.c (working copy) @@ -23828,7 +23828,7 @@ decide_alg (HOST_WIDE_INT count, HOST_WIDE_INT exp { const struct stringop_algs * algs; bool optimize_for_speed; - int max = -1; + int max = 0; const struct processor_costs *cost; int i; bool any_alg_usable_p = false; @@ -23866,7 +23866,7 @@ decide_alg (HOST_WIDE_INT count, HOST_WIDE_INT exp /* If expected size is not known but max size is small enough so inline version is a win, set expected size into the range. */ - if (max > 1 && (unsigned HOST_WIDE_INT) max >= max_size + if (((max > 1 && (unsigned HOST_WIDE_INT) max >= max_size) || max == -1) && expected_size == -1) expected_size = min_size / 2 + max_size / 2; @@ -23955,7 +23955,7 @@ decide_alg (HOST_WIDE_INT count, HOST_WIDE_INT exp *dynamic_check = 128; return loop_1_byte; } - if (max == -1) + if (max <= 0) max = 4096; alg = decide_alg (count, max / 2, min_size, max_size, memset, zero_memset, dynamic_check, noalign);