From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 32546 invoked by alias); 17 Feb 2016 16:10:20 -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 32528 invoked by uid 89); 17 Feb 2016 16:10:20 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=rolled, Continue, sr 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; Wed, 17 Feb 2016 16:10:19 +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 (Postfix) with ESMTPS id DC773821C3; Wed, 17 Feb 2016 16:10:17 +0000 (UTC) Received: from slagheap.utah.redhat.com (ovpn-113-79.phx2.redhat.com [10.3.113.79]) by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u1HGAHfg008775; Wed, 17 Feb 2016 11:10:17 -0500 Subject: Re: [RFC] [P2] [PR tree-optimization/33562] Lowering more complex assignments. To: Richard Biener References: <56BD1EFB.90008@redhat.com> <56BE14B0.9040801@redhat.com> <56C0ACC1.60905@redhat.com> <0D3F08EF-9DC3-4848-AEC7-1AE639464B3D@gmail.com> <56C4217F.2040809@redhat.com> <56C47D5C.7010804@redhat.com> Cc: gcc-patches From: Jeff Law Message-ID: <56C49B69.2090209@redhat.com> Date: Wed, 17 Feb 2016 16:10:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2016-02/txt/msg01199.txt.bz2 On 02/17/2016 07:13 AM, Richard Biener wrote: >> - /* Continue walking until we reach a kill. */ >> - while (!stmt_kills_ref_p (temp, ref)); >> + /* Continue walking until we reach a full kill as a single statement >> + or there are no more live bytes. */ >> + while (!stmt_kills_ref_p (temp, ref) >> + && !(live_bytes && bitmap_empty_p (live_bytes))); > > Just a short quick comment - the above means you only handle partial stores > with no interveaning uses. You don't handle, say > > struct S { struct R { int x; int y; } r; int z; } s; > > s = { {1, 2}, 3 }; > s.r.x = 1; > s.r.y = 2; > struct R r = s.r; > s.z = 3; > > where s = { {1, 2}, 3} is still dead. Right. But handling that has never been part of DSE's design goals. Once there's a use, DSE has always given up. Having said that... > > That is, you don't make use of the live_bytes in the ref_maybe_used_by_stmt_p > check (you can skip uses of only dead bytes). > > Not sure if it makes a difference in practice (compared to the cost it > would take). Not sure either. It doesn't appear that it would be hard to experiment with that to see if it's worth the effort. My gut feeling is we're not going to see this often, if at all, in practice. > > Rather than building ao_refs in clear_bytes_written_by just use > get_ref_base_and_extent > directly. Easy enough to do, but ISTM if we use get_ref_base_and_extent in clear_bytes_written-by, then the other blob of similar code in tree-ssa-dse should be handled in the same way. ie, the code you see in clear_bytes_written_by is almost a direct copy of code already existing in tree-ssa-dse.c (hence my feeling that there's some refactoring of that code that we want to do). > > You don't handle stuff like > > s[i] = { 1, 2 }; > s[i].x = 1; > s[i].y = 1; > > either btw. Correct I believe. IIRC (I think I looked at this during debugging at some point), the ao_ref->max_size field will cover the entire array for this kind of situation because we don't know which element in the array we're hitting (or -1 if we don't know the array's size). I don't see a reasonable way to handle it with an ao_ref style interface unless the variable parts of the address computation are all rolled into the ao_ref->base field. I did look for cases where the initial store was to a varying location and thus max_size covered the entire array with killing stores that eventually covered the entire array (but with each individual killing store having size == max_size) -- the situation never came up in the codes I looked at (gcc & its runtime libraries of course). Jeff