From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 98589 invoked by alias); 14 Feb 2016 18:38:12 -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 98315 invoked by uid 89); 14 Feb 2016 18:38:09 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.6 required=5.0 tests=BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 spammy=filled, HContent-Transfer-Encoding:8bit X-HELO: mail-wm0-f49.google.com Received: from mail-wm0-f49.google.com (HELO mail-wm0-f49.google.com) (74.125.82.49) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-GCM-SHA256 encrypted) ESMTPS; Sun, 14 Feb 2016 18:38:07 +0000 Received: by mail-wm0-f49.google.com with SMTP id g62so82243828wme.0 for ; Sun, 14 Feb 2016 10:38:07 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:user-agent:in-reply-to:references:mime-version :content-transfer-encoding:content-type:subject:from:date:to:cc :message-id; bh=mbt8fwrMv32fDH3r74450paevyQWUsfs5j2YdDVWEFA=; b=DobJ6bAc4T1mPygq4RG1i2qbod/1pqSyJn57TL76ycrPv3QFDdVL0MbWkvSMbWk7sY Vomd2emiJgkLtsXPiafpbI69wbqtaRN4rr5JkfeT4m/yGzOrnF7lezCVF3laF4bChdWS CbEq847GudVvneo6qRiaqOEZ6ut9XY8apr41JVWzPJS5CTrgl+9ruo9685MUJy1y/fwa O2mqmCP8EC3Bl8yUQzQcNOVNgpjj/kr/wa/7gF0cuz4LL19P7Q1jEcuktssXAQ9x9sfb o+WaMJKtOb+13F6Ek9Kt1Qk7orHbgIMWYLCK3sW4iV8ePBHx3jgr0AldCkErfUZxt+iD 3Ocw== X-Gm-Message-State: AG10YOSvogKFj7oclJp3t/uoSTADiI7cqiVKlpYl32zviSeYjIu1+xa8Zb2dmNsI6bKsAw== X-Received: by 10.194.184.171 with SMTP id ev11mr11832063wjc.44.1455475084420; Sun, 14 Feb 2016 10:38:04 -0800 (PST) Received: from android-4c5a376a18c0e957.fritz.box (p4FE9DCD0.dip0.t-ipconnect.de. [79.233.220.208]) by smtp.gmail.com with ESMTPSA id et11sm21709872wjc.30.2016.02.14.10.38.03 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 14 Feb 2016 10:38:03 -0800 (PST) User-Agent: K-9 Mail for Android In-Reply-To: <56C0ACC1.60905@redhat.com> References: <56BD1EFB.90008@redhat.com> <56BE14B0.9040801@redhat.com> <56C0ACC1.60905@redhat.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8 Subject: Re: [RFC] [P2] [PR tree-optimization/33562] Lowering more complex assignments. From: Richard Biener Date: Sun, 14 Feb 2016 18:38:00 -0000 To: Jeff Law CC: gcc-patches Message-ID: <0D3F08EF-9DC3-4848-AEC7-1AE639464B3D@gmail.com> X-IsSubscribed: yes X-SW-Source: 2016-02/txt/msg00940.txt.bz2 On February 14, 2016 5:35:13 PM GMT+01:00, Jeff Law wrote: >On 02/12/2016 10:21 AM, Jeff Law wrote: >>> But really we simply need a better DSE algorithm. >> So the way to fix DSE is to keep the existing algorithm and track the >> hunks of Complex/aggregates that have been set a second time. >> >> My first thought was to implement this as an inverted bitmap. ie, >set >> it to 1 for every byte in the complex/aggregate that is set by the >first >> store. Clear bits for each byte in subsequent stores to the pieces. >If >> the bitmap reaches an empty state, then the initial store is dead. >> >> Adjusting *ref could work too, but would probably be painful if the >> subsequent stores don't happen in a convenient order. >So that was scary easy. We should have done this a long time ago. > >Essentially I call ao_get_ref_base to get the offset/size/max_size >filled in for the first statement. Those are used to initialize the >live bytes bitfield, as long as max_size != -1. > >Then when we have a possible killing statement, we use the ao in a >similar manner to determine which bytes to clear (taking care that the >base is the same between the two references and that in the killing >statement that the size/max_size are the same.). > >When all the live bytes are zero then we've killed the original >statement. > >It's ~20 lines of code. > >I need to pull together some additional tests, but it looks likely >we'll >be able to wrap this up easily for gcc-6. BTW, we had sth like this before but it had both correctness and more importantly scalability issues. Richard. >Jeff