From: Luis Machado <luis.machado@arm.com>
To: Nelson Chu <nelson@rivosinc.com>, binutils@sourceware.org
Cc: Patrick O'Neill <patrick@rivosinc.com>
Subject: Re: [committed 1/2] RISC-V: Improve link time complexity.
Date: Tue, 25 Oct 2022 11:10:47 +0100 [thread overview]
Message-ID: <84a75951-f5a7-fc53-a11a-9a1b964200b7@arm.com> (raw)
In-Reply-To: <20221025013347.68282-1-nelson@rivosinc.com>
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]
next prev parent reply other threads:[~2022-10-25 10:11 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 [this message]
2022-10-26 2:06 ` Nelson Chu
2022-10-26 8:30 ` Luis Machado
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=84a75951-f5a7-fc53-a11a-9a1b964200b7@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).