From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6846 invoked by alias); 8 Sep 2009 10:55:45 -0000 Received: (qmail 6785 invoked by uid 22791); 8 Sep 2009 10:55:44 -0000 X-SWARE-Spam-Status: No, hits=-7.3 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_HI X-Spam-Check-By: sourceware.org Received: from cantor.suse.de (HELO mx1.suse.de) (195.135.220.2) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 08 Sep 2009 10:55:30 +0000 Received: from relay1.suse.de (relay-ext.suse.de [195.135.221.8]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.suse.de (Postfix) with ESMTP id 528B38FEA2; Tue, 8 Sep 2009 12:55:28 +0200 (CEST) Date: Tue, 08 Sep 2009 10:55:00 -0000 From: Michael Matz To: Alex Turjan Cc: gcc@gcc.gnu.org, rsandifor@codesourcery.com, zadeck@naturalbridge.com Subject: Re: question about DSE In-Reply-To: <969088.51632.qm@web62405.mail.re1.yahoo.com> Message-ID: References: <969088.51632.qm@web62405.mail.re1.yahoo.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-IsSubscribed: yes Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org X-SW-Source: 2009-09/txt/msg00159.txt.bz2 Hi, On Tue, 8 Sep 2009, Alex Turjan wrote: > (insn 374 47 52 2 test.c:107 (set (mem/c:SI (plus:PSI (reg/f:PSI 55 ptr15) > (const_int 96 [0x60])) [19 fac_iter+0 S4 A32]) > (reg/v:SI 16 r16 [orig:161 step109 ] [161])) 48 {si_indexed_store_incl_ra} (nil)) An SI store to a MEM of alias set 19 (and a non-trapping while we're at it, the /c marker on the MEM) ... > despite being consumed (in bb3) by the following 2 loads: > (insn 380 71 64 3 test.c:112 (set (reg:HI 1 r1) > (mem:HI (plus:PSI (reg/f:PSI 55 ptr15) > (const_int 96 [0x60])) [0 S2 A16])) 12 {load} (nil)) > > (insn 382 346 65 3 test.c:112 (set (reg:HI 5 r5) > (mem:HI (plus:PSI (reg/f:PSI 55 ptr15) > (const_int 98 [0x62])) [0 S2 A16])) 12 {load} (nil)) ... and two HI loads of MEMs of alias set 0. This should be fine as set 0 aliases with everything. Either you need to open a bugreport with necessary patches to reproduce the above, or make it reproduce on trunk, or you need to debug dse.c yourself. There is one peculiarity about dse.c which might be able to help you in determining the cause. dse.c operates under the assumption that all spill slot accesses generated by reload are using exactly the same alias set and that any such slot is completely unaliased by anything else including stuff with alias set 0. This is done only by the after-reload dse pass. See functions dse_record_singleton_alias_set and friends. Your loads should kill the active stores in function check_mem_read_rtx should you need to debug it that far. My assumption would be these two split loads of HImode are generated by your backend from a given SImode MEM. If so, you need to make sure to copy the MEM_ALIAS_SET, at least for spill slots (better for everything) into the newly generated HImode mems. For spill slots it's not enough to set it to zero. Ciao, Michael.