From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18514 invoked by alias); 30 Jan 2015 05:57:36 -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 18477 invoked by uid 89); 30 Jan 2015 05:57:28 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS,SPF_PASS,T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Fri, 30 Jan 2015 05:57:26 +0000 Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id t0U5vOvt004887 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Fri, 30 Jan 2015 00:57:24 -0500 Received: from [10.3.113.3] ([10.3.113.3]) by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t0U5vNFg022999; Fri, 30 Jan 2015 00:57:24 -0500 Message-ID: <54CB1D43.8020406@redhat.com> Date: Fri, 30 Jan 2015 08:57:00 -0000 From: Jeff Law User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Segher Boessenkool CC: "gcc-patches@gcc.gnu.org >> gcc-patches" Subject: Re: [PATCH][PR target/15184] Fix for direct byte access on x86 References: <54CA4407.5050905@redhat.com> <20150129201331.GD28561@gate.crashing.org> In-Reply-To: <20150129201331.GD28561@gate.crashing.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2015-01/txt/msg02691.txt.bz2 On 01/29/15 13:13, Segher Boessenkool wrote: > On Thu, Jan 29, 2015 at 07:30:31AM -0700, Jeff Law wrote: >> @@ -2643,6 +2644,34 @@ try_combine (rtx_insn *i3, rtx_insn *i2, rtx_insn *i1, rtx_insn *i0, >> || GET_CODE (src) == LSHIFTRT) >> nshift++; >> } >> + >> + /* If I0 loads a memory and I3 sets the same memory, then I2 and I3 >> + are likely manipulating its value. Ideally we'll be able to combine >> + all four insns into a bitfield insertion of some kind. > > "I1 and I2"? > > Very simple patch, nice :-) Thanks. Fixed in the obvious way. I'm also looking at 15596 which is in the same area that affects PPC. I haven't come up with anything good for that one yet. But it feels like it ought to have a similar flow (make_field_assignment creates some interesting RTL, we choose an appropriate split point and the right things should just happen). Jeff