From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22699 invoked by alias); 7 Jun 2011 09:36:58 -0000 Received: (qmail 22690 invoked by uid 22791); 7 Jun 2011 09:36:57 -0000 X-SWARE-Spam-Status: No, hits=-2.4 required=5.0 tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,RFC_ABUSE_POST X-Spam-Check-By: sourceware.org Received: from mail-wy0-f175.google.com (HELO mail-wy0-f175.google.com) (74.125.82.175) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 07 Jun 2011 09:36:42 +0000 Received: by wye20 with SMTP id 20so4045121wye.20 for ; Tue, 07 Jun 2011 02:36:40 -0700 (PDT) MIME-Version: 1.0 Received: by 10.227.199.21 with SMTP id eq21mr5957989wbb.101.1307439400729; Tue, 07 Jun 2011 02:36:40 -0700 (PDT) Received: by 10.227.37.152 with HTTP; Tue, 7 Jun 2011 02:36:40 -0700 (PDT) In-Reply-To: References: <20110601231202.224188ad.basile@starynkevitch.net> Date: Tue, 07 Jun 2011 09:36:00 -0000 Message-ID: Subject: Re: Dump before flag From: Richard Guenther To: Xinliang David Li Cc: GCC Patches , Diego Novillo Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 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-06/txt/msg00487.txt.bz2 On Mon, Jun 6, 2011 at 6:20 PM, Xinliang David Li wrot= e: >> >> Your patch doesn't really improve this but adds to the confusion. >> >> + =A0/* Override dump TODOs. =A0*/ >> + =A0if (dump_file && (pass->todo_flags_finish & TODO_dump_func) >> + =A0 =A0 =A0&& (dump_flags & TDF_BEFORE)) >> + =A0 =A0{ >> + =A0 =A0 =A0pass->todo_flags_finish &=3D ~TODO_dump_func; >> + =A0 =A0 =A0pass->todo_flags_start |=3D TODO_dump_func; >> + =A0 =A0} >> >> and certainly writing to pass is not ok. =A0And the TDF_BEFORE flag >> looks misplaced as it controls TODOs, not dumping behavior. >> Yes, it's a mess right now but the above looks like a hack ontop >> of that mess (maybe because of it, but well ...). >> > > How about removing dumping TODO completely -- this can be done easily > -- I don't understand why pass wants extra control on the dumping if > user already asked for dumping -- it is annoying to see empty IR dump > for a pass when I want to see it. > >> At least I would have expected to also get the dump after the >> pass, not only the one before it with this dump flag. >> >> Now, why can't you look at the previous pass output for the >> before-dump (as I do usually)? > > For one thing, you need to either remember what is the previous pass, > or dump all passes which for large files can take very long time. Even > with all the dumps, you will need to eyeballing to find the previous > pass which may or may not have the IR dumped. > > How about removing dump TODO? Yeah, I think this would go in the right direction. Currently some passes do not dump function bodies because they presumably do no IL modification. But this is certainly the minority (and some passes do not dump bodies even though they are modifying the IL ...). So I'd say we should by default dump function bodies. Note that there are three useful dumping positions (maybe four), before todo-start, after todo-start, before todo-finish and after todo-fini= sh. By default we'd want after todo-finish. When we no longer dump via a TODO then we could indeed use dump-flags to control this (maybe -original for the body before todo-start). What to others think? Richard. > Thanks, > > David > > >> >> Richard. >> >