2.35 x64 assembler more than 70 times slower than 2.34?

[Franz Sirl]

Am 2020-08-19 um 11:28 schrieb Martin Liška:
> On 8/19/20 11:20 AM, Franz Sirl wrote:
>> Am 2020-08-19 um 10:48 schrieb Martin Liška:
>>> On 8/19/20 10:38 AM, Franz Sirl wrote:
>>>> Hi,
>>>>
>>>> I just stumbled over an extreme slowdown in assembler performance. 
>>>> On a 265 MByte .s file (gcc10 assembly output of a 27000 line C 
>>>> source compiled with debug + ASAN + UBSAN) the assembler of 2.34 
>>>> takes ~49-59sec, but the 2.35 assembler takes ~65-74min. Both use 
>>>> about 3.6 GBytes of memory. That's quite a performance regression, 
>>>> so hasn't anyone else seen this? Any timed mass rebuilds with 
>>>> binutils-2.35 yet?
>>>
>>> Btw. would it be possible to share the .s file to me?
>>> Or is it a private project?
>>
>> Hi Martin,
>>
>> unfortunately this is a private project. Additionally the most 
>> affected file is a disassembler of a CPU that might still be under NDA.
>> But that at least makes the structure quite clear, it's a lot of 
>> nested switch/case where each case has lots of macros wrapped in 
>> do/while(0). I'll check if I can reproduce it with one of GCCs 
>> insn-*.c files.
> 
> I see. Do you generate the code with an optimization level (-O2 or so)?

Yes, -O2 -fno-inline (as inlining doesn't really help here and just 
blows up compile time).
Actually I was trying to speed up the compile (refactor case blocks into 
functions) when I noticed that more time is spent in GAS than GCC.

>>
>> BTW, I just did a build with debug info and a quick check shows that a 
>> CTRL-C usually seems to end up here:
> 
> Can you please provide perf record && perf report?

I'm not so familiar with perf, what would be a good perf record line in 
this case? Something like "perf record -F 99 as-new ..."?

With perf top it looks like this after a few minutes:
   97.75%  as-new            [.] _bfd_elf_write_secondary_reloc_section
    2.22%  [kernel]          [k] 0xffffffffb2a00ae0
    0.03%  as-new            [.] bfd_putl64
    0.00%  as-new            [.] bfd_elf64_write_relocs
    0.00%  as-new            [.] bfd_elf64_swap_reloca_out

Even later:
   97.95%  as-new            [.] _bfd_elf_write_secondary_reloc_section
    2.04%  [kernel]          [k] 0xffffffffb2a00ae0
    0.00%  as-new            [.] bfd_elf64_write_relocs
    0.00%  as-new            [.] bfd_map_over_sections
    0.00%  as-new            [.] bfd_arch_bits_per_address

> 
>>
>> Program received signal SIGINT, Interrupt.
>> 0x00000000004781db in _bfd_elf_write_secondary_reloc_section 
>> (abfd=0x7b63c0, sec=<optimized out>) at 
>> ../../binutils-2.35-branch/bfd/elf.c:12770
>> 12770         if (hdr->sh_type == SHT_RELA
>> (gdb) bt
>> #0  0x00000000004781db in _bfd_elf_write_secondary_reloc_section 
>> (abfd=0x7b63c0, sec=<optimized out>) at 
> 
> I bet it will be a different root case.
> Can you please bisect which bintuils revision is responsible for that?

Well, that was easy, I just took a wild guess according to git log and 
was lucky. The responsible commit is:

commit a8e14f4cc2badfcf959f5e2cc57a941dc43f72d4
Author: Nick Clifton <nickc@redhat.com>
Date:   Thu Mar 5 15:47:15 2020 +0000

     Add support for ELF files which contain multiple reloc sections 
which all target the same section.

Starting with this commit the assembler slows down for me.

Franz