2.35 x64 assembler more than 70 times slower than 2.34?

[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)?

> 
> 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?

> 
> 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 ../../binutils-2.35-branch/bfd/elf.c:12770
> #1  0x0000000000462591 in bfd_elf64_write_relocs (abfd=0x7b63c0, sec=0x45d44a08, data=0x7fffffffd88c) at ../../binutils-2.35-branch/bfd/elfcode.h:990
> #2  0x00000000004500ac in bfd_map_over_sections (abfd=abfd@entry=0x7b63c0, operation=0x462300 <bfd_elf64_write_relocs>, user_storage=user_storage@entry=0x7fffffffd88c)
>      at ../../binutils-2.35-branch/bfd/section.c:1379
> #3  0x000000000046f37d in _bfd_elf_write_object_contents (abfd=0x7b63c0) at ../../binutils-2.35-branch/bfd/elf.c:6675
> #4  0x000000000044d4ea in bfd_close (abfd=0x7b63c0) at ../../binutils-2.35-branch/bfd/opncls.c:775
> #5  0x00000000004194b6 in output_file_close (filename=0x7a03b0 "long-as2.35-assemble-time-sample.o") at ../../binutils-2.35-branch/gas/output-file.c:64
> #6  0x0000000000406550 in close_output_file () at ../../binutils-2.35-branch/gas/as.c:1158
> #7  0x00000000004e7602 in xatexit_cleanup () at ../../binutils-2.35-branch/libiberty/xatexit.c:98
> #8  0x00000000004e76c1 in xexit (code=code@entry=0) at ../../binutils-2.35-branch/libiberty/xexit.c:50
> #9  0x0000000000404988 in main (argc=<optimized out>, argv=<optimized out>) at ../../binutils-2.35-branch/gas/as.c:1499

I bet it will be a different root case.
Can you please bisect which bintuils revision is responsible for that?

Thanks,
Martin

> 
> I'll wait for your patch to trickle through the ML and try it then. So far I only got the [v2 0/9] message.
> 
> Franz