2.35 x64 assembler more than 70 times slower than 2.34?

[Franz Sirl]

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.

BTW, I just did a build with debug info and a quick check shows that a 
CTRL-C usually seems to end up here:

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