BRBUILDLOG:command:br_prepare_repo binutils_gdb master ---> git remote prune origin ---> git pull --all Fetching origin Already up-to-date. Current top commit: commit 258bf0ee3748d4354e13daf00f02266cafa96389 Author: Richard Biener Date: Fri Feb 14 08:32:53 2020 +0100 [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-14 Richard Biener * dwarf2/read.c (lnp_state_machine::handle_special_opcode): Apply CSE on expression with division operators. Outstanding patch: BRBUILDLOG:starttime:1581670305 BRBUILDLOG:stoptime:1581670308 BRBUILDLOG:duration:3 BRBUILDLOG:status:0