Skip to content

RISC-V: Add bit manipulation extension multilibs #6

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 1 commit into from
Jun 29, 2022

Conversation

stephanosio
Copy link
Member

This commit adds the following multilibs that support the target
configurations with the bit manipulation (Bitmanip) extension:

  • rv32im_zicsr_zifencei_zba_zbb_zbc_zbs
  • rv32emc_zicsr_zifencei_zba_zbb_zbc_zbs
  • rv64im_zicsr_zifencei_zba_zbb_zbc_zbs
  • rv64imac_zicsr_zifencei_zba_zbb_zbc_zbs

These multilibs are mapped to the other compatible target
configurations to improve the configuration coverage.

This commit also adds a new non-Bitmanip capable multilib for the
rv64im_zicsr_zifencei in order to better align the coverage of the
RV64I to that of the RV32I.

Signed-off-by: Stephanos Ioannidis root@stephanos.io

This commit adds the following multilibs that support the target
configurations with the bit manipulation (Bitmanip) extension:

* rv32im_zicsr_zifencei_zba_zbb_zbc_zbs
* rv32emc_zicsr_zifencei_zba_zbb_zbc_zbs
* rv64im_zicsr_zifencei_zba_zbb_zbc_zbs
* rv64imac_zicsr_zifencei_zba_zbb_zbc_zbs

These multilibs are mapped to the other compatible target
configurations to improve the configuration coverage.

This commit also adds a new non-Bitmanip capable multilib for the
`rv64im_zicsr_zifencei` in order to better align the coverage of the
RV64I to that of the RV32I.

Signed-off-by: Stephanos Ioannidis <root@stephanos.io>
Copy link
Member Author

@stephanosio stephanosio left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@stephanosio stephanosio merged commit 1c8fef6 into zephyr-gcc-12.1.0 Jun 29, 2022
@stephanosio stephanosio deleted the riscv_bitmanip branch July 7, 2022 17:11
nashif pushed a commit that referenced this pull request May 31, 2025
…o_debug_section [PR116614]

cat abc.C
  #define A(n) struct T##n {} t##n;
  #define B(n) A(n##0) A(n##1) A(n##2) A(n##3) A(n##4) A(n##5) A(n##6) A(n##7) A(n##8) A(n##9)
  #define C(n) B(n##0) B(n##1) B(n##2) B(n##3) B(n##4) B(n##5) B(n##6) B(n##7) B(n##8) B(n##9)
  #define D(n) C(n##0) C(n##1) C(n##2) C(n##3) C(n##4) C(n##5) C(n##6) C(n##7) C(n##8) C(n##9)
  #define E(n) D(n##0) D(n##1) D(n##2) D(n##3) D(n##4) D(n##5) D(n##6) D(n##7) D(n##8) D(n##9)
  E(1) E(2) E(3)
  int main () { return 0; }
./xg++ -B ./ -o abc{.o,.C} -flto -flto-partition=1to1 -O2 -g -fdebug-types-section -c
./xgcc -B ./ -o abc{,.o} -flto -flto-partition=1to1 -O2
(not included in testsuite as it takes a while to compile) FAILs with
lto-wrapper: fatal error: Too many copied sections: Operation not supported
compilation terminated.
/usr/bin/ld: error: lto-wrapper failed
collect2: error: ld returned 1 exit status

The following patch fixes that.  Most of the 64K+ section support for
reading and writing was already there years ago (and especially reading used
quite often already) and a further bug fixed in it in the PR104617 fix.

Yet, the fix isn't solely about removing the
  if (new_i - 1 >= SHN_LORESERVE)
    {
      *err = ENOTSUP;
      return "Too many copied sections";
    }
5 lines, the missing part was that the function only handled reading of
the .symtab_shndx section but not copying/updating of it.
If the result has less than 64K-epsilon sections, that actually wasn't
needed, but e.g. with -fdebug-types-section one can exceed that pretty
easily (reported to us on WebKitGtk build on ppc64le).
Updating the section is slightly more complicated, because it basically
needs to be done in lock step with updating the .symtab section, if one
doesn't need to use SHN_XINDEX in there, the section should (or should be
updated to) contain SHN_UNDEF entry, otherwise needs to have whatever would
be overwise stored but couldn't fit.  But repeating due to that all the
symtab decisions what to discard and how to rewrite it would be ugly.

So, the patch instead emits the .symtab_shndx section (or sections) last
and prepares the content during the .symtab processing and in a second
pass when going just through .symtab_shndx sections just uses the saved
content.

2024-09-07  Jakub Jelinek  <jakub@redhat.com>

	PR lto/116614
	* simple-object-elf.c (SHN_COMMON): Align comment with neighbouring
	comments.
	(SHN_HIRESERVE): Use uppercase hex digits instead of lowercase for
	consistency.
	(simple_object_elf_find_sections): Formatting fixes.
	(simple_object_elf_fetch_attributes): Likewise.
	(simple_object_elf_attributes_merge): Likewise.
	(simple_object_elf_start_write): Likewise.
	(simple_object_elf_write_ehdr): Likewise.
	(simple_object_elf_write_shdr): Likewise.
	(simple_object_elf_write_to_file): Likewise.
	(simple_object_elf_copy_lto_debug_section): Likewise.  Don't fail for
	new_i - 1 >= SHN_LORESERVE, instead arrange in that case to copy
	over .symtab_shndx sections, though emit those last and compute their
	section content when processing associated .symtab sections.  Handle
	simple_object_internal_read failure even in the .symtab_shndx reading
	case.

(cherry picked from commit bb8dd09)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant