From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22811 invoked by alias); 30 Aug 2013 16:50:02 -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 22794 invoked by uid 89); 30 Aug 2013 16:50:02 -0000 Received: from mail-ie0-f177.google.com (HELO mail-ie0-f177.google.com) (209.85.223.177) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-SHA encrypted) ESMTPS; Fri, 30 Aug 2013 16:50:02 +0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-3.4 required=5.0 tests=BAYES_00,KHOP_THREADED,NO_RELAYS autolearn=ham version=3.3.2 X-HELO: mail-ie0-f177.google.com Received: by mail-ie0-f177.google.com with SMTP id e14so3661942iej.22 for ; Fri, 30 Aug 2013 09:50:00 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=+qDrMlt0rRuTx+tNPCssAInhXoYzKIDdDD1bynZKd+I=; b=V9C7Twe3enTk3vqvvfeX7DX2GctbwuEA0KH0N8AhqHG2aVPxiq+hSPOFlBsjGk0jSH C9ztWtm30M3h0IUZr71cYDuD1lOeXSWP7bwNyB14+5lYdWFNJJZ/CNFtMkfjizpk2N2k AItWwDTc+3bafuBwuS2x8WTxwabVPZpidPVPBgYf9SVFtzGuAIJO/ndmA/kEYnQmdAvw EMj4Q4IPCrMm2mzSAEDianozCqXdSCSnUUQTrKxqy2FQIGKen5BYtoG78PbdzdCttDz1 pdqGMkCNti3HBklPTOI8Cp3wfKtICQ9YfsevhjRcqcCmKLLK4g8j7PEkgy486s1f5Su9 Tipw== X-Gm-Message-State: ALoCoQmXR4g6z3gQKSOyebt5qDXtusPaYSWFUEjD3PjzW6E1CzJ+XJj3U1/DCUPxCYYRDu5zh+gYzrRhUDPjcbLVfq/adONIJCDul6hqn0BVFJIYjlEp47takve/Il8khaakcdfiIofDMHy8yu+6BpOnMH5KfmwemcTAlROLGzKwVmYw/xl2HJ1Yukc57aciYJ8Y9oVPo9w4Da2mjorPvMUCdmQ5ftY+cg== MIME-Version: 1.0 X-Received: by 10.42.24.73 with SMTP id v9mr694901icb.76.1377881399945; Fri, 30 Aug 2013 09:49:59 -0700 (PDT) Received: by 10.231.165.136 with HTTP; Fri, 30 Aug 2013 09:49:59 -0700 (PDT) In-Reply-To: <20130830162611.GR21876@tucnak.zalov.cz> References: <20130830162611.GR21876@tucnak.zalov.cz> Date: Fri, 30 Aug 2013 17:02:00 -0000 Message-ID: Subject: Re: Fix PR middle-end/57370 From: Easwaran Raman To: Jakub Jelinek Cc: Richard Biener , GCC Patches Content-Type: text/plain; charset=ISO-8859-1 X-SW-Source: 2013-08/txt/msg01914.txt.bz2 On Fri, Aug 30, 2013 at 9:26 AM, Jakub Jelinek wrote: > On Fri, Aug 30, 2013 at 09:13:34AM -0700, Easwaran Raman wrote: >> >> There are more similar failures reported in >> >> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57393 and I have attached >> >> the updated patch there. Shall I send that for review? Apart from the >> >> debug statement issue, almost all the bugs are due to dependence >> >> violation because certain newly inserted statements do not have the >> >> right UID. Instead of trying to catch all of them, will it be better >> >> if I check if the stmt has a proper uid (non-zero if it is not the >> >> first stmt) and assign a sensible value at the point where it is used >> >> (find_insert_point and appears_later_in_bb) instead of where the stmt >> >> is created? I think that would be less brittle. >> > >> > In the end all this placement stuff should be reverted and done as >> > post-processing after reassoc is finished. You can remember the >> > inserted stmts that are candidates for moving (just set a pass-local >> > flag on them) and assign UIDs for the whole function after all stmts >> > are inserted. >> >> The problem is we need sane UID values as reassoc is happening - not >> after it is finished. As it process each stmt in reassoc_bb, it might >> generate new stmts which might have to be compared in >> find_insert_point or appears_later_in_bb. > > A new stmt will be created with UID 0 and in case there is stmt movement, > you could zero the UID during movement. Then, you can just special case > UID zero when you are looking at UIDs. As on trunk/4.8 gsi_for_stmt is > O(1), you can easily walk a couple of previous and/or later stmts and look > for the first non-zero UID around it, and treat it as if the UID was > previous non-zero UID + 0.5 or next non-zero UID - 0.5. And, if you see > too many consecutive statements with UID 0 (more than some constant, 32?), > just reassign UIDs to the whole bb. Or you could initially assign UIDs > with some gaps, then keep filling those gaps and once you fill them, > renumber again with new gaps. > Jakub Yes, this is pretty much what I was proposing. The current implementation doesn't rely on UIDs being unique - they only have to be monotonically non-decreasing. So, when a UID of 0 is encountered, go up till a non-zero UID is found and then go down and assign this non-zero UID. This effectively implies that each UID-0 stmt is visited at most twice. I don't think we need to check if I see more than certain number of UID-0 stmts and redo the entire BB. - Easwaran