[Bug sanitizer/110074] New: code bloat with -fprofile-args + -fsanitize=bounds

[Bug sanitizer/110074] New: code bloat with -fprofile-args + -fsanitize=bounds

[arnd at linaro dot org]

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

            Bug ID: 110074
           Summary: code bloat with -fprofile-args + -fsanitize=bounds
           Product: gcc
           Version: unknown
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: sanitizer
          Assignee: unassigned at gcc dot gnu.org
          Reporter: arnd at linaro dot org
                CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
                    jakub at gcc dot gnu.org, kcc at gcc dot gnu.org, marxin at gcc dot gnu.org
  Target Milestone: ---

Created attachment 55231
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55231&action=edit
simplified standalone version of linux kernel twofish cipher

I noticed warnings about excessive stack usage in the Linux kernel in multiple
files when both UBSAN and GCOV are enabled:

crypto/twofish_common.c:683:1: error: the frame size of 2040 bytes is larger
than 1024 bytes [-Werror=frame-larger-than=]
drivers/media/platform/mediatek/vcodec/vdec/vdec_vp9_req_lat_if.c:1589:1:
error: the frame size of 1696 bytes is larger than 1400 bytes
[-Werror=frame-larger-than=]
drivers/media/platform/verisilicon/hantro_g2_vp9_dec.c:754:1: error: the frame
size of 1260 bytes is larger than 1024 bytes [-Werror=frame-larger-than=]
drivers/staging/media/rkvdec/rkvdec-vp9.c:1042:1: error: the frame size of 2176
bytes is larger than 2048 bytes [-Werror=frame-larger-than=]

This shows up across architectures in certain kernel configurations, but I have
managed to come up with a simplified testcase based on the twofish cipher that
lets me reproduce this in all gcc versions I tried (gcc-5.5 through 13.1):

$ gcc-13 -O2 -Wframe-larger-than=100 -fprofile-arcs -fsanitize=bounds
-fsanitize=thread -c twofish.c
twofish.c: In function ‘__twofish_setkey’:
twofish.c:662:1: warning: the frame size of 2320 bytes is larger than 100 bytes
[-Wframe-larger-than=]

Removing either the -fprofile-arcs or the -fsanitize=bounds option avoids this
and produces  more readable code. See https://godbolt.org/z/zvf7YqK5K for a
demonstration using the attached testcase.

Nick Desaulniers pointed out a recent change to LLVM that addresses a similar
problem by not trying to sanitize code that was generated by gcov, see
https://reviews.llvm.org/D150460

[Bug gcov-profile/110074] code bloat with -fprofile-arcs + -fsanitize=bounds

[pinskia at gcc dot gnu.org]

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

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
          Component|sanitizer                   |gcov-profile

--- Comment #1 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
>Nick Desaulniers pointed out a recent change to LLVM that addresses a similar problem by not trying to sanitize code that was generated by gcov

Well in the case of GCC, it is the order of sanitizer and profile-arcs is the
opposite of clang/LLVM's. That is the issue is we need not to generate
profile-arcs for code added by the sanitizer.

[Bug gcov-profile/110074] -fprofile-arcs profiles arcs generated by -fsanitize=bounds

[pinskia at gcc dot gnu.org]

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

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2023-06-01
     Ever confirmed|0                           |1
            Summary|code bloat with             |-fprofile-arcs profiles
                   |-fprofile-arcs +            |arcs generated by
                   |-fsanitize=bounds           |-fsanitize=bounds

--- Comment #2 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Simplified example:
```
int array[104];

int f(int t)
{
        return array[t];
}
```

Compile this at -fprofile-arcs  -O2 -fsanitize=bounds and in .optimized we
have:
```
  PROF_edge_counter_5 = __gcov0._Z1fi[0];
  PROF_edge_counter_6 = PROF_edge_counter_5 + 1;
  __gcov0._Z1fi[0] = PROF_edge_counter_6;
  # DEBUG BEGIN_STMT
  _11 = (sizetype) t_1(D);
  if (_11 >= 104)
    goto <bb 3>; [0.05%]
  else
    goto <bb 4>; [99.95%]

  <bb 3> [local count: 536864]:
  _12 = (unsigned long) t_1(D);
  __builtin___ubsan_handle_out_of_bounds (&*.Lubsan_data0, _12);

  <bb 4> [local count: 1073741824]:
  PROF_edge_counter_7 = __gcov0._Z1fi[1];
  PROF_edge_counter_8 = PROF_edge_counter_7 + 1;
  __gcov0._Z1fi[1] = PROF_edge_counter_8;
  _4 = array[t_1(D)];
```

But we do really need to profile that arc?

[Bug gcov-profile/110074] -fprofile-arcs profiles arcs generated by -fsanitize=bounds

[rguenth at gcc dot gnu.org]

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

--- Comment #3 from Richard Biener <rguenth at gcc dot gnu.org> ---
The profiling code cannot tell that apart, and yes, with sanitize recover we
should.  In principle we could detect all sanitizer calls to be in cold paths
during profile estimation and have a profile instrumentation mode ignoring
statically predicted (with good quality) branches.  But that would mean to
build a shadow CFG to compute the counter inserts then.