From patchwork Thu Feb 13 14:23:06 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Tom de Vries X-Patchwork-Id: 38029 Received: (qmail 110517 invoked by alias); 13 Feb 2020 14:23:11 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Delivered-To: mailing list gdb-patches@sourceware.org Received: (qmail 110509 invoked by uid 89); 13 Feb 2020 14:23:10 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-25.2 required=5.0 tests=AWL, BAYES_00, GIT_PATCH_0, GIT_PATCH_1, GIT_PATCH_2, GIT_PATCH_3, SPF_PASS autolearn=ham version=3.3.1 spammy=Care, Samples X-HELO: mx2.suse.de Received: from mx2.suse.de (HELO mx2.suse.de) (195.135.220.15) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 13 Feb 2020 14:23:09 +0000 Received: from relay2.suse.de (unknown [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id 89050B01D for ; Thu, 13 Feb 2020 14:23:07 +0000 (UTC) Subject: Re: [PATCH] Speedup lnp_state_machine::handle_special_opcode To: Richard Biener , gdb-patches@sourceware.org References: From: Tom de Vries Message-ID: Date: Thu, 13 Feb 2020 15:23:06 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.4.1 MIME-Version: 1.0 In-Reply-To: X-IsSubscribed: yes On 13-02-2020 14:03, Richard Biener wrote: > Care to pick up this one-time patch without myself becoming familiar > with gdb testing & patch submission? Of course. Added ChangeLog entry, build and reg-tested on x86_64-linux. Thanks, - Tom [gdb] Speedup lnp_state_machine::handle_special_opcode I see for some program at gdb startup: ... Samples: 102K of event 'cycles:pu', Event count (approx.): 91710925103 Overhead Command Shared Object Symbol 15.21% gdb gdb [.] lnp_state_machine::handle_special ... where the divisions are the places we stall. The following micro-optimizes things but it smells like m_line_header->line_range is constant, likewise probably m_line_header->maximum_ops_per_instruction so eventually the divisions could be avoided completely with some lookup table. Well. Micro-optimizing with this patch improves things (don't expect [load] CSE over the gdbarch_adjust_dwarf2_line call). Build and reg-tested on x86_64-linux. gdb/ChangeLog: 2020-02-13 Tom de Vries * dwarf2/read.c (lnp_state_machine::handle_special_opcode): Apply CSE on expression with division operators. --- gdb/dwarf2/read.c | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/gdb/dwarf2/read.c b/gdb/dwarf2/read.c index 7edbd9d7df..e74383e01d 100644 --- a/gdb/dwarf2/read.c +++ b/gdb/dwarf2/read.c @@ -19812,16 +19812,16 @@ void lnp_state_machine::handle_special_opcode (unsigned char op_code) { unsigned char adj_opcode = op_code - m_line_header->opcode_base; - CORE_ADDR addr_adj = (((m_op_index - + (adj_opcode / m_line_header->line_range)) + unsigned char adj_opcode_d = adj_opcode / m_line_header->line_range; + unsigned char adj_opcode_r = adj_opcode % m_line_header->line_range; + CORE_ADDR addr_adj = (((m_op_index + adj_opcode_d) / m_line_header->maximum_ops_per_instruction) * m_line_header->minimum_instruction_length); m_address += gdbarch_adjust_dwarf2_line (m_gdbarch, addr_adj, true); - m_op_index = ((m_op_index + (adj_opcode / m_line_header->line_range)) + m_op_index = ((m_op_index + adj_opcode_d) % m_line_header->maximum_ops_per_instruction); - int line_delta = (m_line_header->line_base - + (adj_opcode % m_line_header->line_range)); + int line_delta = m_line_header->line_base + adj_opcode_r; advance_line (line_delta); record_line (false); m_discriminator = 0;