[PATCH v3] LoongArch: Batch-delete bytes at the end of each relax trip

[WANG Xuerui]

On 6/16/25 14:52, mengqinggang wrote:
>
> 在 2025/6/14 下午10:15, WANG Xuerui 写道:
>> [snip]
>>
>> +static void
>> +loongarch_relax_perform_deletes (bfd *abfd, asection *sec,
>> +                 struct bfd_link_info *link_info)
>>   {
>>     unsigned int i, symcount;
>>     bfd_vma toaddr = sec->size;
>> @@ -4737,30 +4877,72 @@ loongarch_relax_delete_bytes (bfd *abfd,
>>     Elf_Internal_Shdr *symtab_hdr = &elf_tdata (abfd)->symtab_hdr;
>>     unsigned int sec_shndx = _bfd_elf_section_from_bfd_section (abfd, 
>> sec);
>>     struct bfd_elf_section_data *data = elf_section_data (sec);
>> -  bfd_byte *contents = data->this_hdr.contents;
>> +  bfd_byte *contents = data->this_hdr.contents, *contents_end = NULL;
>>     struct relr_entry *relr = loongarch_elf_section_data (sec)->relr;
>>     struct loongarch_elf_link_hash_table *htab =
>>       loongarch_elf_hash_table (link_info);
>>     struct relr_entry *relr_end = NULL;
>> +  splay_tree pdops = htab->pending_delete_ops;
>> +  splay_tree_node node1 = NULL, node2 = NULL;
>>       if (htab->relr_count)
>>       relr_end = htab->relr + htab->relr_count;
>>   -  /* Actually delete the bytes.  */
>> -  sec->size -= count;
>> -  memmove (contents + addr, contents + addr + count, toaddr - addr - 
>> count);
>> +  BFD_ASSERT (pdops != NULL);
>> +  node1 = splay_tree_min (pdops);
>> +
>> +  if (node1 == NULL)
>> +    /* No pending delete ops, nothing to do.  */
>> +    return;
>> +
>> +  /* Actually delete the bytes.  For each delete op the pointer 
>> arithmetics
>> +     look like this:
>> +
>> +        node1->key -\                /- node2->key
>> +            |<-- op1->size -->|        |
>> +            v          v        v
>> + ...---------------xxxxxxxxxxxxxxxxxxx---------xxxxxxxxxxx----...
>> +                            ^
>> +                node1->key + op1->size -/
>
> These pointers seem to not change after delete op. The delete op just 
> copy (node1->key+op1->size, node2->key) to node1->key.
>
Sorry I didn't understand this, isn't there a "node1 = node2" below in 
the for statement's expression 3 position? But indeed the memmove 
destination is not node1->key as the illustration might suggest 
otherwise, maybe I can clarify that in a v4. What do you think?