From patchwork Thu Nov 24 13:34:33 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: 698846 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 3tPgGB5BP0z9ry7 for ; Fri, 25 Nov 2016 00:36:18 +1100 (AEDT) Authentication-Results: ozlabs.org; dkim=pass (1024-bit key; unprotected) header.d=gcc.gnu.org header.i=@gcc.gnu.org header.b="mHQnClNZ"; 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=Wt9pduCwTcP1p6WWw63DRCOtBLW4O4+0orBKJiDoehTN03ar+M Qa45ila7RDL8vse7E3Lu+ucQx/kMrJGk3VLSm5rFPXuCvcHUa8s6maE0xgJkkux1 IztWGYGLM8LXDQq2/GCdybk0awB1adxX1TSQ1yNgNuO1OdbOLIl6BZI84= 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=eHUC3dkjwk+kL3r2dO62FkIfiaM=; b=mHQnClNZm1FxDpGEXUyT oYNpxY0IaWm1T+5tM238gxDT9zOtgPuleLWTnX1KJ+X9agGulkQryq+/5y5qo6Fk 1qYq9xYcz+OTZSkcl360ewR2FJr3PANq1WxUZQdlgpqcOntaP/7CiMidlBvMtqx+ 43pRafgBiQmYzdQ315ErnOk= Received: (qmail 41784 invoked by alias); 24 Nov 2016 13:36:10 -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 41768 invoked by uid 89); 24 Nov 2016 13:36:09 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-4.9 required=5.0 tests=BAYES_00, RP_MATCHES_RCVD, SPF_PASS autolearn=ham version=3.3.2 spammy= 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, 24 Nov 2016 13:36:08 +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, 24 Nov 2016 14:35:58 +0100 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, 24 Nov 2016 14:36:03 +0100 User-agent: mu4e 0.9.17; emacs 24.5.1 From: Senthil Kumar Selvaraj To: GCC Patches CC: Richard Biener Subject: [Patch, tentative] Use MOVE_MAX_PIECES instead of MOVE_MAX in gimple_fold_builtin_memory_op Date: Thu, 24 Nov 2016 19:04:33 +0530 Message-ID: <871sy180ie.fsf@atmel.com> MIME-Version: 1.0 X-IsSubscribed: yes Hi, I've been analyzing a failing regtest (gcc.dg/strlenopt-8.c) for the avr target. I found that the (dump) failure is because there are 4 instances of memcpy, while the testcase expects only 2 for a non-strict align target like the avr. Comparing that with a dump generated by x64_64-pc-linux, I found that the extra memcpy's come from the forwprop pass, when it replaces strcat with strlen and memcpy. For x86_64, the memcpy generated gets folded into a load/store in gimple_fold_builtin_memory_op. That doesn't happen for the avr because len (2) happens to be bigger than MOVE_MAX (1). The avr can only move 1 byte efficiently from reg <-> memory, but it's more efficient to load and store 2 bytes than to call memcpy, so MOVE_MAX_PIECES is set to 2. Given that gimple_fold_builtin_memory_op gets to choose between leaving the memcpy call as is, or breaking it down to a by-pieces move, shouldn't it use MOVE_MAX_PIECES instead of MOV_MAX? That is what the below patch does, and that makes the test pass. Does this sound right? Regards Senthil Index: gcc/gimple-fold.c =================================================================== --- gcc/gimple-fold.c (revision 242741) +++ gcc/gimple-fold.c (working copy) @@ -703,7 +703,7 @@ src_align = get_pointer_alignment (src); dest_align = get_pointer_alignment (dest); if (tree_fits_uhwi_p (len) - && compare_tree_int (len, MOVE_MAX) <= 0 + && compare_tree_int (len, MOVE_MAX_PIECES) <= 0 /* ??? Don't transform copies from strings with known length this confuses the tree-ssa-strlen.c. This doesn't handle the case in gcc.dg/strlenopt-8.c which is XFAILed for that