public inbox for binutils@sourceware.org
 help / color / mirror / Atom feed
From: Luis Machado <luis.machado@arm.com>
To: Nelson Chu <nelson@rivosinc.com>
Cc: binutils@sourceware.org, Patrick O'Neill <patrick@rivosinc.com>
Subject: Re: [committed 1/2] RISC-V: Improve link time complexity.
Date: Wed, 26 Oct 2022 09:30:59 +0100	[thread overview]
Message-ID: <3f637fda-b910-980c-12f5-36655328b311@arm.com> (raw)
In-Reply-To: <CAPpQWtD80RvbrcsN-UupskTpw9sf2CNNp6__BOGT6gc=ziJJwg@mail.gmail.com>

Hi,

On 10/26/22 03:06, Nelson Chu wrote:
> Hi Luis,
> 
> Although I cannot reproduce the case from my side, does the following
> fix work for you?
> 
> diff --git a/bfd/elfnn-riscv.c b/bfd/elfnn-riscv.c
> index cf852636c9c..73e422dd57a 100644
> --- a/bfd/elfnn-riscv.c
> +++ b/bfd/elfnn-riscv.c
> @@ -4253,7 +4253,8 @@ riscv_relax_resolve_delete_relocs (bfd *abfd,
>         rel->r_info = ELFNN_R_INFO (0, R_RISCV_NONE);
> 
>         /* Skip ahead to the next delete reloc.  */
> -      i = rel_next != NULL ? rel_next - relocs - 1 : sec->reloc_count;
> +      i = rel_next != NULL ? (unsigned int) (rel_next - relocs - 1)
> +                          : sec->reloc_count;
>       }
> 
>     return true;

That fixes it for me.

Thanks,
Luis

> 
> Thanks
> Nelson
> 
> On Tue, Oct 25, 2022 at 6:11 PM Luis Machado <luis.machado@arm.com> wrote:
>>
>> Hi Nelson,
>>
>> On 10/25/22 02:33, Nelson Chu wrote:
>>> From: Patrick O'Neill <patrick@rivosinc.com>
>>>
>>> The riscv port does deletion and symbol table update for each relocation
>>> while relaxing, so we are moving section bytes and scanning symbol table once
>>> for each relocation.  Compared to microblaze port, they record the relaxation
>>> changes into a table, then do the deletion and symbol table update once per
>>> section, rather than per relocation.  Therefore, they should have better link
>>> time complexity than us.
>>>
>>> To improve the link time complexity, this patch try to make the deletion in
>>> linear time.  Compared to record the relaxation changes into a table, we
>>> replace the unused relocation with R_RISCV_DELETE for the deleted bytes, and
>>> then resolve them at the end of the section.  Assuming the number of
>>> R_RISCV_DELETE is m, and the number of symbols is n, the total link complexity
>>> should be O(m) for moving section bytes, and O(m*n^2) for symbol table update.
>>> If we record the relaxation changes into the table, and then sort the symbol
>>> table by values, then probably can reduce the time complexity to O(m*n*log(n))
>>> for updating symbol table, but it doesn't seem worth it for now.
>>>
>>> bfd/
>>>       * elfnn-riscv.c (_riscv_relax_delete_bytes): Renamed from
>>>       riscv_relax_delete_bytes, updated to reduce the tiem complexity to O(m)
>>>       for memmove.
>>>       (typedef relax_delete_t): Function pointer declaration of delete functions.
>>>       (riscv_relax_delete_bytes): Can choose to use _riscv_relax_delete_piecewise
>>>       or _riscv_relax_delete_immediate for deletion.
>>>       (_riscv_relax_delete_piecewise): Just mark the deleted bytes as R_RISCV_DELETE.
>>>       (_riscv_relax_delete_immediate): Delete some bytes from a section while
>>>       relaxing.
>>>       (riscv_relax_resolve_delete_relocs): Delete the bytes for R_RISCV_DELETE
>>>       relocations from a section, at the end of _bfd_riscv_relax_section.
>>>       (_bfd_riscv_relax_call): Mark deleted bytes as R_RISCV_DELETE by reusing
>>>       R_RISCV_RELAX.
>>>       (_bfd_riscv_relax_lui): Likewise, but reuse R_RISCV_HI20 for lui, and reuse
>>>       R_RISCV_RELAX for c.lui.
>>>       (_bfd_riscv_relax_tls_le): Likewise, but resue R_RISCV_TPREL_HI20 and
>>>       R_RISCV_TPREL_ADD.
>>>       (_bfd_riscv_relax_pc): Likewise, but resue R_RISCV_PCREL_HI20 for auipc.
>>>       (_bfd_riscv_relax_align): Updated, don't need to resue relocation since
>>>       calling _riscv_relax_delete_immediate.
>>>       (_bfd_riscv_relax_delete): Removed.
>>>       (_bfd_riscv_relax_section): Set riscv_relax_delete_bytes for each relax_func,
>>>       to delete bytes immediately or later.  Call riscv_relax_resolve_delete_relocs
>>>       to delete bytes for DELETE relocations from a section.
>>> ---
>>>    bfd/elfnn-riscv.c | 180 +++++++++++++++++++++++++++++++++-------------
>>>    1 file changed, 131 insertions(+), 49 deletions(-)
>>>
>>
>> This seems to cause build failures due to a couple warnings (Werror). I can reproduce it on
>> armhf Ubuntu 22.04, with the following configure line:
>>
>> configure --enable-targets=all --enable-64-bit-bfd
>>
>> The following warnings show up:
>>
>> elfnn-riscv.c: In function ‘riscv_relax_resolve_delete_relocs’:
>> elfnn-riscv.c:4256:30: error: operand of ‘?:’ changes signedness from ‘int’ to ‘unsigned int’ due to unsignedness of other operand [-Werror=sign-compare]
>>
>> elfnn-riscv.c: In function ‘riscv_relax_resolve_delete_relocs’:
>> elfnn-riscv.c:4256:30: error: operand of ‘?:’ changes signedness from ‘int’ to ‘unsigned int’ due to unsignedness of other operand [-Werror=sign-compare]


      reply	other threads:[~2022-10-26  8:31 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-10-25  1:33 Nelson Chu
2022-10-25  1:33 ` [committed 2/2] RISC-V: Should reset `again' flag for _bfd_riscv_relax_pc Nelson Chu
2022-10-25  4:36 ` [committed 1/2] RISC-V: Improve link time complexity Nelson Chu
2022-10-25 10:10 ` Luis Machado
2022-10-26  2:06   ` Nelson Chu
2022-10-26  8:30     ` Luis Machado [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=3f637fda-b910-980c-12f5-36655328b311@arm.com \
    --to=luis.machado@arm.com \
    --cc=binutils@sourceware.org \
    --cc=nelson@rivosinc.com \
    --cc=patrick@rivosinc.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).