From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <hubicka@kam.mff.cuni.cz>
Received: from nikam.ms.mff.cuni.cz (nikam.ms.mff.cuni.cz [195.113.20.16])
 by sourceware.org (Postfix) with ESMTPS id 57CA03858430
 for <gcc-patches@gcc.gnu.org>; Tue, 16 Nov 2021 12:30:51 +0000 (GMT)
DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 57CA03858430
Received: by nikam.ms.mff.cuni.cz (Postfix, from userid 16202)
 id 4D66B2807CB; Tue, 16 Nov 2021 13:30:50 +0100 (CET)
Date: Tue, 16 Nov 2021 13:30:50 +0100
From: Jan Hubicka <hubicka@kam.mff.cuni.cz>
To: Richard Biener <rguenther@suse.de>
Cc: gcc-patches@gcc.gnu.org
Subject: Re: Use modref kills in tree-ssa-dse
Message-ID: <20211116123050.GJ71052@kam.mff.cuni.cz>
References: <20211114232310.GD42690@kam.mff.cuni.cz>
 <46408584-8380-346n-2034-n945no4q9878@fhfr.qr>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <46408584-8380-346n-2034-n945no4q9878@fhfr.qr>
User-Agent: Mutt/1.10.1 (2018-07-13)
X-Spam-Status: No, score=-5.7 required=5.0 tests=BAYES_00, DKIM_SIGNED,
 DKIM_VALID, DKIM_VALID_AU, RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE,
 SPF_NONE, TXREP autolearn=ham autolearn_force=no version=3.4.4
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on
 server2.sourceware.org
X-BeenThere: gcc-patches@gcc.gnu.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Gcc-patches mailing list <gcc-patches.gcc.gnu.org>
List-Unsubscribe: <https://gcc.gnu.org/mailman/options/gcc-patches>,
 <mailto:gcc-patches-request@gcc.gnu.org?subject=unsubscribe>
List-Archive: <https://gcc.gnu.org/pipermail/gcc-patches/>
List-Post: <mailto:gcc-patches@gcc.gnu.org>
List-Help: <mailto:gcc-patches-request@gcc.gnu.org?subject=help>
List-Subscribe: <https://gcc.gnu.org/mailman/listinfo/gcc-patches>,
 <mailto:gcc-patches-request@gcc.gnu.org?subject=subscribe>
X-List-Received-Date: Tue, 16 Nov 2021 12:30:53 -0000

> 
> Not sure, tree-ssa-dse.c doesn't seem to handle MEM_REF with offset?
> 
> VN has adjust_offsets_for_equal_base_address for this purpose.  I
> agree that some common functionality like
> 
> bool
> get_relative_extent_of (const ao_ref *base, const ao_ref *ref,
>                         poly_int64 *offset);
> 
> that computes [offset, offset + ref->[max_]size] of REF adjusted as to
> make ao_ref_base have the same address (or return false if not
> possible).  Then [ base->offset, base->offset + base->max_size ]
> can be compared against that.

OK, I will look into that.
> > +  if (valid_ao_ref_for_dse (write)
> > +      && operand_equal_p (write->base, ref->base, OEP_ADDRESS_OF)
> > +      && known_eq (write->size, write->max_size)
> > +      && normalize_ref (write, ref)
> 
> normalize_ref alters 'write', I think we should work on a local
> copy here.  See live_bytes_read which takes a copy of 'use_ref'.

We never proces same write twice (get_ao_ref is always constructing
fresh copy), so this should be safe.  Or shall I turn the write
parameter to "ao_ref write" instead of "ao_ref *write" just to be sure
we do not break infuture?

Thank you,
Honza