From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19340 invoked by alias); 7 Jul 2014 20:15:52 -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 19302 invoked by uid 89); 7 Jul 2014 20:15:49 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-3.4 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD autolearn=ham version=3.3.2 X-HELO: mail2-relais-roc.national.inria.fr Received: from mail2-relais-roc.national.inria.fr (HELO mail2-relais-roc.national.inria.fr) (192.134.164.83) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (CAMELLIA256-SHA encrypted) ESMTPS; Mon, 07 Jul 2014 20:15:45 +0000 Received: from stedding.saclay.inria.fr ([193.55.250.194]) by mail2-relais-roc.national.inria.fr with ESMTP/TLS/AES128-SHA; 07 Jul 2014 22:15:26 +0200 Received: from glisse (helo=localhost) by stedding.saclay.inria.fr with local-esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1X4FJt-0001w0-S1; Mon, 07 Jul 2014 22:15:25 +0200 Date: Mon, 07 Jul 2014 20:15:00 -0000 From: Marc Glisse To: Richard Biener cc: GCC Patches Subject: Re: SRA: don't drop clobbers In-Reply-To: Message-ID: References: User-Agent: Alpine 2.11 (DEB 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-SW-Source: 2014-07/txt/msg00502.txt.bz2 On Mon, 7 Jul 2014, Richard Biener wrote: >> The main idea of these patches is that when we read from a place that >> was clobbered, instead of dropping the clobber and reading what was >> there before, we can use a variable with a default definition to mark >> that the content is undefined. This enables both warnings and >> optimizations. >> >> The previous patch makes update_ssa handle replacing clobbers with >> default definitions when a variable doesn't have its address taken >> anymore. When SRA scalarizes, it creates a new variable and relies on >> update_ssa to finish the job. So I am inserting a clobber on the new >> variable so that update_ssa knows to use a default definition. > > OK. But can't SRA simply replace the reads with undef SSA names when > the use is dominated by a clobber? I guess it could, but it seems safer and much simpler to avoid duplicating the logic. SRA creates a new variable and replaces uses of the old one by uses of the new one. update_address_taken then handles replacing the new variable by a bunch of SSA_NAMEs, tracking which use corresponds to which def, so it seems natural to let it handle the clobber as well. Also, conceptually, saying that when the full variable is clobbered the subvariable is clobbered as well is a rather obvious operation. Otherwise, I could create an extra variable tmp, with the same type as the new variable, and replace the clobber by an assignment of the default definition of tmp to the new variable. update_address_taken will then see a regular assignment and handle it as usual (create a new SSA_NAME for it). So instead of creating a clobber that is immediatly replaced with a NOP, this creates an extra SSA_NAME that only disappears in the next propagation pass. Handling the reads myself directly in SRA and replacing them with undef SSA_NAMEs doesn't seem to fit well with how SRA works. It would certainly be possible, but would require quite a bit of new code. Also, the domination relation between the clobber and the reads is not always obvious and may require some PHIs in between. -- Marc Glisse