From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14701 invoked by alias); 6 Apr 2011 16:59:20 -0000 Received: (qmail 14691 invoked by uid 22791); 6 Apr 2011 16:59:19 -0000 X-SWARE-Spam-Status: No, hits=-6.8 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_HI,SPF_HELO_PASS,TW_CF,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 06 Apr 2011 16:59:11 +0000 Received: from int-mx12.intmail.prod.int.phx2.redhat.com (int-mx12.intmail.prod.int.phx2.redhat.com [10.5.11.25]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id p36GwctK009702 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 6 Apr 2011 12:58:48 -0400 Received: from ns3.rdu.redhat.com (ns3.rdu.redhat.com [10.11.255.199]) by int-mx12.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id p36Gqg71004431; Wed, 6 Apr 2011 12:52:42 -0400 Received: from [10.3.113.84] (ovpn-113-84.phx2.redhat.com [10.3.113.84]) by ns3.rdu.redhat.com (8.13.8/8.13.8) with ESMTP id p36GqeCT022640; Wed, 6 Apr 2011 12:52:41 -0400 Message-ID: <4D9C9A58.6050205@redhat.com> Date: Wed, 06 Apr 2011 16:59:00 -0000 From: Jeff Law User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.15) Gecko/20110307 Fedora/3.1.9-0.39.b3pre.fc14 Lightning/1.0b3pre Thunderbird/3.1.9 MIME-Version: 1.0 To: Eric Botcazou CC: gcc-patches@gcc.gnu.org Subject: Re: [RFC] Remove kludge in commit_edge_insertions References: <201104042307.56517.ebotcazou@adacore.com> In-Reply-To: <201104042307.56517.ebotcazou@adacore.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-IsSubscribed: yes 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 X-SW-Source: 2011-04/txt/msg00488.txt.bz2 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 04/04/11 15:07, Eric Botcazou wrote: > commit_edge_insertions contains this kludge: > > /* In the old rtl CFG API, it was OK to insert control flow on an > edge, apparently? In cfglayout mode, this will *not* work, and > the caller is responsible for making sure that control flow is > valid at all times. */ > if (current_ir_type () == IR_RTL_CFGLAYOUT) > return; > > blocks = sbitmap_alloc (last_basic_block); > sbitmap_zero (blocks); > FOR_EACH_BB (bb) > if (bb->aux) > { > SET_BIT (blocks, bb->index); > /* Check for forgotten bb->aux values before commit_edge_insertions > call. */ > gcc_assert (bb->aux == &bb->aux); > bb->aux = NULL; > } > find_many_sub_basic_blocks (blocks); > sbitmap_free (blocks); > > > At least on x86/x86-64, there is apparently only one case where control flow > insns are inserted on edges: when the prologue is inserted on the entry edge. > Once this is accounted for, the above kludge can be removed, provided that the > force_nonfallthru RTL routine is enhanced to preserve the loop nest structure. > The result is the attached patch, bootstrapped/regtested on x86 and x86-64. > > I'll be testing it on IA-64 and SPARC over the next few days if there is an > agreement that this is a progress. What about when we have a PHI, which we eliminate by inserting insns on edges and those insns actually form a loop? You can see an example of this in PR48389. I'm not terribly familiar with any of this cfg code these days, so there may be a reason why this isn't going to be a problem that I'm not aware of. I just happened to be looking at 48389 and remembered your RFC. jeff -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJNnJpYAAoJEBRtltQi2kC7QawH/3pVtwugDPR8H6Ai8CyyZSWX jm+sMFFQulccWt6KRA6OzGcYYiU+NCXCJCtqHTl5XWqStxzipOHKhKkJFX7qEfaL eRcxdfV4a9YU6LrIZxzBN3AirW6G1kc6OVjvJLxbkMLtrlGOGbdviyUczdiPD+mS oa+ece+ALigr9vEVQ5ezd6ggnD5mMprrciV+sJdZOk8dExV8RNqvAz2dnBEtkeV2 khwXVe/PL+aBDokLr8gGcCYfJosYF+1zg1MUgugB2k8JrLibZDQjbfJKiowM03bp GXPDhJRyEIE8voy4dqBEvAt5pzbptkktaNIMC95m5oXyiFDf/thEAkJqKuKjYZg= =aajv -----END PGP SIGNATURE-----