From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23372 invoked by alias); 23 Jun 2009 22:27:40 -0000 Received: (qmail 23364 invoked by uid 22791); 23 Jun 2009 22:27:40 -0000 X-SWARE-Spam-Status: No, hits=-1.8 required=5.0 tests=AWL,BAYES_00,SARE_MSGID_LONG40,SPF_PASS X-Spam-Check-By: sourceware.org Received: from mail-fx0-f222.google.com (HELO mail-fx0-f222.google.com) (209.85.220.222) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 23 Jun 2009 22:27:33 +0000 Received: by fxm22 with SMTP id 22so455948fxm.8 for ; Tue, 23 Jun 2009 15:27:30 -0700 (PDT) MIME-Version: 1.0 Received: by 10.204.71.15 with SMTP id f15mr534372bkj.42.1245796049776; Tue, 23 Jun 2009 15:27:29 -0700 (PDT) Date: Tue, 23 Jun 2009 22:50:00 -0000 Message-ID: <571f6b510906231527h453fe581i5cf85b785b587b86@mail.gmail.com> Subject: Question about dead_or_predicable From: Steven Bosscher To: Richard Henderson , GCC Mailing List Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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-06/txt/msg00548.txt.bz2 Hi, I have a question about ifcvt.c:dead_or_predicable. This function is pretty complicated and it's not really clear to me what it is doing. But I'll have to understand what is going on because there is a bug in this function that I would like to fix (see http://gcc.gnu.org/PR40525). The code I don't understand, is the part where the changes are actually applied. This code starts with the following comment: 33547 rth 33547 rth no_body: 33547 rth /* We don't want to use normal invert_jump or redirect_jump because 33547 rth we don't want to delete_insn called. Also, we want to do our own 33547 rth change group management. */ 33547 rth The comment doesn't explain *why* we don't want delete_insn to be called, or why we want to do our own change group management. I am guessing this code was required when ifcvt.c was contributed (the file appears in r33547). The code has, at this point, proven that MERGE_BB is "dead or predicable" and it now tries to rewire the insns stream and the CFG to apply the transformation. Perhaps historically the changes to the jump from old_dest to new_dest had to be in the same change group as the changes to predicate the insns. But now there is OTHER_BB, which is not documented, and for which the changes to the jumps are done *after* the change group for everything else has been applied. The OTHER_BB is a bit newer (but only a little bit) than the first revision in SVN of ifcvt.c. These changes are applied directly, i.e. not in the change group, and it isn't even verified that the changes are applied successfully?! What I would like to do, is to apply the change group *before* changing the jumps. That way, I can move the apply_change_group() call into the "if (HAVE_conditional_execution)" block higher up in dead_or_predicable, and try the non-conditional execution case if predicating the insns fails. When neither succeeds, we're done. When one or the other succeeds, we change the jumps and rewire the CFG. But since in one case (from merge_bb to new_dest) the changes are applied as part of a change group, and in the other case (other_bb to new_dest) the changes are not, I'm confused. Can I assume that the changes to the jumps never fail? Or should the changes to redirect other_bb to new_dest actually be part of the big change group (or at least, should it be somehow verified that these changes are applied successfully) and is it a bug in ifcvt.c that these changes are applied without checks? Hope the question makes enough sense for someone to help me out here :-) Ciao! Steven