From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19573 invoked by alias); 18 Nov 2001 13:09:22 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org Received: (qmail 19552 invoked from network); 18 Nov 2001 13:09:21 -0000 Received: from unknown (HELO vlsi1.ultra.nyu.edu) (128.122.140.213) by sourceware.cygnus.com with SMTP; 18 Nov 2001 13:09:21 -0000 Received: by vlsi1.ultra.nyu.edu (4.1/1.34) id AA00282; Sun, 18 Nov 01 08:16:11 EST Date: Tue, 06 Nov 2001 03:18:00 -0000 From: kenner@vlsi1.ultra.nyu.edu (Richard Kenner) Message-Id: <10111181316.AA00282@vlsi1.ultra.nyu.edu> To: dan@cgsoftware.com Subject: Re: should MEM tracking be able to optimize this? Cc: gcc@gcc.gnu.org X-SW-Source: 2001-11/txt/msg00300.txt.bz2 Actually, I just saw how to do it. Right now, there's a function that looks at a tree for the offset computation and returns the highest power of two that it's known to be a multiple of. That can be replaced by a routine that returns the highest known multiple (or we can have both routines). We add a field to the mem attribute structure which we could call MEM_STRIDE. If it's nonzero, then MEM_OFFSET does not represent a constant offset, but an assertion that the actual offset is MEM_OFFSET + J * MEM_STRIDE for some value of J. Then if we have two MEMs with the same stride, we can take the offset modulo the stride and if those (offset, size) pairs don't conflict, we know the two MEMs can't. Is anybody interested in doing this?