2.35 x64 assembler more than 70 times slower than 2.34?

[Martin Liška]

On 8/19/20 12:38 PM, Franz Sirl wrote:
> 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.

Nice catch! That corresponds to the hottest function in perf profile: _bfd_elf_write_secondary_reloc_section.

I bet we want to create a bugzilla entry for this. And please CC Nick to the bug.

Martin

> 
> Franz
>