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 <rguenther@suse.de>
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  <rguenther@suse.de>
    
     * dwarf2/read.c (lnp_state_machine::handle_special_opcode): Apply CSE
     on expression with division operators.

Outstanding patch:
BRBUILDLOG:starttime:1581669546
BRBUILDLOG:stoptime:1581669550
BRBUILDLOG:duration:4
BRBUILDLOG:status:0