From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20602 invoked by alias); 23 Nov 2007 23:56:52 -0000 Received: (qmail 20531 invoked by uid 22791); 23 Nov 2007 23:56:52 -0000 X-Spam-Check-By: sourceware.org Received: from nz-out-0506.google.com (HELO nz-out-0506.google.com) (64.233.162.229) by sourceware.org (qpsmtpd/0.31) with ESMTP; Fri, 23 Nov 2007 23:56:48 +0000 Received: by nz-out-0506.google.com with SMTP id i11so3037291nzh for ; Fri, 23 Nov 2007 15:56:47 -0800 (PST) Received: by 10.142.187.2 with SMTP id k2mr394490wff.1195862207109; Fri, 23 Nov 2007 15:56:47 -0800 (PST) Received: by 10.143.44.8 with HTTP; Fri, 23 Nov 2007 15:56:47 -0800 (PST) Message-ID: <571f6b510711231556o439e7bbek9ab4855079bab51d@mail.gmail.com> Date: Sat, 24 Nov 2007 10:27:00 -0000 From: "Steven Bosscher" To: "Alexandre Oliva" Subject: Re: Designs for better debug info in GCC Cc: "Mark Mitchell" , "Ian Lance Taylor" , "Richard Guenther" , gcc-patches@gcc.gnu.org, gcc@gcc.gnu.org In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <571f6b510711121208m2bf7c77fp884f52d458df118b@mail.gmail.com> 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: 2007-11/txt/msg00600.txt.bz2 On Nov 23, 2007 9:45 PM, Alexandre Oliva wrote: > So, yes, debug stmts and insns are notes in the sense that they don't > output code. Like USE insns, labels, empty asm insns and other > UNSPECs. But wait, those are insns, not notes. And they do generate > code, just not in the .text section, but rather in .debug sections. All of them relate to code generation though. Without them, we create wrong code. I'm aware of how you feel about debug info and correctness and so on. > So, what's this prejudice against debug insns? Why do you regard them > as notes rather than insns? What worries me is that GCC will have to special-case DEBUG_INSN everywhere where it looks at INSNs. One can already see some of that happening on your branch. Apparently, you can't treat DEBUG_INSN just like any other normal insn. What I see happening with your DEBUG_INSN approach, is that all passes that use NEXT_INSN/PREV_INSN will have to special-case DEBUG_INSN in addition to the NOTE_P or INSN_P checks that they already have. I have seen too many bugs with passes who forgot to look through notes to feel comfortable about adding another not-a-note-but-also-not-an-insn like thing to the insn stream. The fact that DEBUG_INSN also has real operands that are not really real operands is bound to confuse the matter even more. Life with proper insn and operands iterators for RTL would be so much easier, but for the moment I fear you're just going to see a lot of duplication of ugly conditionals and bugs where such conditionals are forgotten/overlooked/missing. So to summarize: I'm just worried your approach is going to make GCC even slower, buggier, more difficult to maintain and more difficult to understand and modify. And the benefit, well, let's just say I'm not convinced that less elaborate efforts are not sufficient. (And to be perfectly honest, I think GCC has bigger issues to solve than getting perfect debug info -- such as getting compile times of a linux kernel down ;-)) Gr. Steven