From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 38161 invoked by alias); 8 Feb 2018 16:05:03 -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 38152 invoked by uid 89); 8 Feb 2018 16:05:02 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-3.3 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.2 spammy= X-HELO: mail-it0-f53.google.com Received: from mail-it0-f53.google.com (HELO mail-it0-f53.google.com) (209.85.214.53) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 08 Feb 2018 16:05:01 +0000 Received: by mail-it0-f53.google.com with SMTP id k6so7004709ita.3 for ; Thu, 08 Feb 2018 08:05:01 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Kw5fbFjgyYVfulBkPTFKpzUc0i5ZgGqj8oD6g4y9T3A=; b=RA15zoqQ7noira8N4RV9uLUqB589ybSpyIMnpZzZf5UZNEOWnliQ/rPzJKZAlGpwgL JcuNd4FitKX4e97IwZJ7lytG1x4v0ATw8rcFDIJNE8esyevmROomDJ5M9d9gORwe7hGS cbFVgvSqqbv3kKd46aFt9tmHmbkb3lg09io2y9YtwWnLjlJO/5siGWu61azOScThnzaK OQHaGYwRx1P8fzRssNvJQ6cHXmwYE+issHmY2rwEq6xmbokTEE8wk8pIaqYCh5UMXa8r TBlPbJxaGg5+DS4ZUBNRBhOetclj3LAFYDnjBRLaJmdFqRss7oJRuq+y+3HDLMu86KxL yWXQ== X-Gm-Message-State: APf1xPAOuyYVSyvGQvjg1BMP8QSdPcDcGImd1jeOU2g9hO9dCdMFEs57 lIJd2eXXlQVLU7DkImBOPyVrCMtRP38yB5wpjPC/8Q== X-Google-Smtp-Source: AH8x225f5IHN6iV3FIO9cEJ5sSy/PiXta7MaHd2HsGH1UkXgmWTew0LKNrAOBUnb3WvrIebThOm71H3JxMwavZBh4bg= X-Received: by 10.36.83.148 with SMTP id n142mr2102058itb.10.1518105899496; Thu, 08 Feb 2018 08:04:59 -0800 (PST) MIME-Version: 1.0 Received: by 10.107.17.206 with HTTP; Thu, 8 Feb 2018 08:04:39 -0800 (PST) In-Reply-To: References: <20171110023448.28164-7-aoliva@redhat.com> <7d731476-256b-28c3-69fe-e28c116281d1@redhat.com> <309c52a4-e2cb-2cc4-a31f-c57b717d10c3@redhat.com> From: Jason Merrill Date: Thu, 08 Feb 2018 16:05:00 -0000 Message-ID: Subject: Re: [SFN+LVU+IEPM v4 7/9] [LVU] Introduce location views To: Alexandre Oliva Cc: Jeff Law , Richard Biener , Jakub Jelinek , gcc-patches Content-Type: text/plain; charset="UTF-8" X-IsSubscribed: yes X-SW-Source: 2018-02/txt/msg00433.txt.bz2 On Thu, Feb 8, 2018 at 7:56 AM, Alexandre Oliva wrote: > On Feb 7, 2018, Jason Merrill wrote: > >> OK, that makes sense. But I'm still uncomfortable with choosing an >> existing opcode for that purpose, which previously would have been >> chosen just for reasons of encoding complexity and size. > > Well, there's a good reason we didn't used to output this opcode: it's > nearly always the case that you're better off using a special opcode or > DW_LNS_advance_pc, that encodes the offset as uleb128 instead of a fixed > size. The only exceptions I can think of are offsets that have the most > significant bits set in the representable range for > DW_LNS_fixed_advance_pc (the uleb128 representation for > DW_LNS_advance_pc would end up taking an extra byte if insns don't get > more than byte alignment), and VLIW machines, in which the > DW_LNS_advance_pc operand needs to be multiplied by the ops-per-insns > (but also divided by the min-insn-length). So, unless you're creating a > gap of 16KiB to 64KiB in the middle of a function on an ISA such as > x86*, that has insns as small as 1 byte, you'll only use > DW_LNS_fixed_advance_pc when the assembler can't encode uleb128 offsets, > as stated in the DWARF specs. Which is often true of non-gas assemblers, isn't it? > Well, now there's one more case for using > it, and it's a rare one as well. I didn't think it made sense to add > yet another opcode with a fixed-size operand for that. So, if I've got this right: The most conservative approach to updating the address is DW_LNE_set_address, but we definitely want that to reset the view because it's used for e.g. starting a new function. And if it resets the view, we need to be careful not to use it more than once for the same address. Special opcodes are only generated by the assembler from .loc directives, so we use symbolic views and let the assembler decide whether or not they reset the view. If we don't have that assembler support, and don't want to use DW_LNE_set_address, that leaves DW_LNS_advance_pc and DW_LNS_fixed_advance_pc. The former could be used by the assembler in cases when special opcodes can't express the necessary change compactly, whereas the latter won't be, so it's a better choice for this situation. And since we don't know whether the increment will be zero, we don't want it to reset the view. OK, that makes sense. Though I expect this will come up again when the DWARF committee looks at the proposal. > But then again, even it was an opcode used more often, it wouldn't be a > significant problem to assign it the special behavior of not resetting > the view counter. Views don't have to be reset for the whole thing to > work, we just need some means for the compiler (who doesn't know all > offsets) and debug info consumers (who do) to keep view numbers in sync. > A single opcode for the compiler to signal to the consumer that it > wasn't sure a smallish offset would be nonzero is enough, and > DW_LNS_fixed_advance_pc provides us with just what we need, without any > complications of having to compute a special opcode, or compute a > compiler-unknown offset times min-insn-length and have that encoded in > uleb128. > >> Thanks, it would be good to have this overview in a comment somewhere. > > You meant just these two paragraphs (like below), or the whole thing? I meant just the two paragraphs, thanks. Jason