[Bug other/111976] New: Large constant zero-valued objects should go in .bss rather than .rodata

[Bug other/111976] New: Large constant zero-valued objects should go in .bss rather than .rodata

[redbeard0531 at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111976

            Bug ID: 111976
           Summary: Large constant zero-valued objects should go in .bss
                    rather than .rodata
           Product: gcc
           Version: unknown
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: other
          Assignee: unassigned at gcc dot gnu.org
          Reporter: redbeard0531 at gmail dot com
  Target Milestone: ---

Right now constant objects always go in .rodata. This is nice because it will
give a nice loud error if you ever write to it. However, .rodata takes up space
in the binary file and in memory at runtime. If you instead put it in .bss it
takes up no space in the binary file and, at least on linux, it gets backed by
a single zero-filled page of physical memory. Ideally there would be something
like .robss which gave you the best of both worlds, but this is admittedly
niche for all the effort to add a new section like that. I think the best
option is to leave it in .rodata for non-optimized builds to catch bugs, but
when optimizing, especially with -Os, put it in .bss.

Repro https://www.godbolt.org/z/3rWvTrsTv:

constexpr int GB = 1024*1024*1024;

// Goes in .bss - no space in binary or runtime.
char nonconst_zeros[GB] = {};

// Goes in .rodata - expensive in binary size and runtime memory.
extern const char const_zeros[GB]; // force usage
const char const_zeros[GB] = {};


        .globl  const_zeros
        .section        .rodata
        .align 32
        .type   const_zeros, @object
        .size   const_zeros, 1073741824
const_zeros:
        .zero   1073741824


        .globl  nonconst_zeros
        .bss
        .align 32
        .type   nonconst_zeros, @object
        .size   nonconst_zeros, 1073741824
nonconst_zeros:
        .zero   1073741824

[Bug other/111976] Large constant zero-valued objects should go in .bss rather than .rodata

[redbeard0531 at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111976

--- Comment #1 from Mathias Stearn <redbeard0531 at gmail dot com> ---
Just to be clear, I think we should only do this for "large" objects or
collections of objects. If you did it for small objects in general, there is a
risk that they will spread out mutable data that is written to over more pages,
so that you end up with more runtime anonymous pages, rather than read-only
pages backed by the file cache, so they end up being more expensive. I think a
good rule to prevent this would be to only do it for objects larger than a
page, and possibly add page alignment to them. It may also be possible to
collect enough smaller objects together to make it worth doing this. Not sure
how often that occurs in practice though.

Also at -Os it may make sense to do this for any size object putting since
small objects in .bss will still shrink the binary size. Not sure how users of
-Os would react to tradeoffs involving runtime memory consumption vs binary
size.

[Bug middle-end/111976] Large constant zero-valued objects should go in .bss rather than .rodata

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111976

--- Comment #2 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Note some file systems do have the concept of zero pages too.

[Bug middle-end/111976] Large constant zero-valued objects should go in .bss rather than .rodata

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111976

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Last reconfirmed|                            |2023-10-27
             Status|UNCONFIRMED                 |NEW
     Ever confirmed|0                           |1

--- Comment #3 from Richard Biener <rguenth at gcc dot gnu.org> ---
Similar to -fzero-initialized-in-bss we could have -fzero-rodata-in-bss maybe,
but note that can also have security implications.  A special .robss section
might be nice (it could also be "mergeable" with a flag, losing distinct
addresses for distinct objects).  With -fdata-sections this optimization
could be performed by the linker as well.