public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug rtl-optimization/107047] New: load introduced of struct fields after assigning it to a local variable
@ 2022-09-27  7:25 absoler at smail dot nju.edu.cn
  2022-09-27  9:10 ` [Bug middle-end/107047] " rguenth at gcc dot gnu.org
                   ` (2 more replies)
  0 siblings, 3 replies; 4+ messages in thread
From: absoler at smail dot nju.edu.cn @ 2022-09-27  7:25 UTC (permalink / raw)
  To: gcc-bugs

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

            Bug ID: 107047
           Summary: load introduced of struct fields after assigning it to
                    a local variable
           Product: gcc
           Version: 12.1.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: rtl-optimization
          Assignee: unassigned at gcc dot gnu.org
          Reporter: absoler at smail dot nju.edu.cn
  Target Milestone: ---

for gcc-12.1.0, with this code:

struct S6 {
   short  f0;
   char  f1;
   int  f2;
};

struct S6 g_36 = {2UL,4L,0x32B3D10AL};
int g_48 = (-1L);


void func_30() {
    struct S6 f[4][7];
    f[1][6] = g_36;
    if (f[1][6].f0 || f[1][6].f1)
        g_48 = f[1][6].f1;
}

when compiled with -O1 option, generated binaries will be like:

0000000000401186 <func_30>:
  401186:       48 83 ec 70             sub    $0x70,%rsp
  40118a:       f7 05 d4 2e 00 00 ff    testl  $0xffffff,0x2ed4(%rip)        #
404068 <g_36>
  401191:       ff ff 00 
  401194:       74 0d                   je     4011a3 <func_30+0x1d>
  401196:       0f be 05 cd 2e 00 00    movsbl 0x2ecd(%rip),%eax        #
40406a <g_36+0x2>
  40119d:       89 05 bd 2e 00 00       mov    %eax,0x2ebd(%rip)        #
404060 <g_48>
  4011a3:       48 83 c4 70             add    $0x70,%rsp
  4011a7:       c3                      retq   

we can see the use of f[1][6] is replaced by g_36 in the if-condition and "g_48
= f[1][6].f1", and the f is not optimized away.

^ permalink raw reply	[flat|nested] 4+ messages in thread

* [Bug middle-end/107047] load introduced of struct fields after assigning it to a local variable
  2022-09-27  7:25 [Bug rtl-optimization/107047] New: load introduced of struct fields after assigning it to a local variable absoler at smail dot nju.edu.cn
@ 2022-09-27  9:10 ` rguenth at gcc dot gnu.org
  2022-10-05 20:02 ` pinskia at gcc dot gnu.org
  2022-10-26  8:31 ` [Bug middle-end/107047] load introduced of struct/union " absoler at smail dot nju.edu.cn
  2 siblings, 0 replies; 4+ messages in thread
From: rguenth at gcc dot gnu.org @ 2022-09-27  9:10 UTC (permalink / raw)
  To: gcc-bugs

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2022-09-27
           Keywords|                            |missed-optimization
      Known to fail|                            |12.2.1, 13.0
     Ever confirmed|0                           |1
          Component|rtl-optimization            |middle-end

--- Comment #1 from Richard Biener <rguenth at gcc dot gnu.org> ---
Confirmed, we see

  <bb 2> [local count: 1073741824]:
  f[1][6] = g_36;
  _1 = BIT_FIELD_REF <f[1][6], 32, 0>;
  _8 = _1 & 16777215;
  if (_8 != 0)

VN probably sees the def but it doesn't consider replacing the use with
a BIT_FIELD_REF of g_36, it just translates the ref but doesn't find
any definition to CSE from.

SRA says

Candidate (1991): f
Too big to totally scalarize: f (UID: 1991)
Created a replacement for f offset: 848, size: 8: f$1$6$f1D.1996

Access trees for f (UID: 1991):
access { base = (1991)'f', offset = 832, size = 64, expr = f[1][6], type =
struct S6, reverse = 0, grp_read = 1, grp_write = 1, grp_assignment_read = 1,
grp_assignment_write = 1, grp_scalar_read = 0, grp_scalar_write = 0,
grp_total_scalarization = 0, grp_hint = 0, grp_covered = 0,
grp_unscalarizable_region = 0, grp_unscalarized_data = 1, grp_same_access_path
= 1, grp_partial_lhs = 0, grp_to_be_replaced = 0, grp_to_be_debug_replaced = 0}
* access { base = (1991)'f', offset = 848, size = 8, expr = f[1][6].f1, type =
char, reverse = 0, grp_read = 1, grp_write = 1, grp_assignment_read = 1,
grp_assignment_write = 1, grp_scalar_read = 1, grp_scalar_write = 0,
grp_total_scalarization = 0, grp_hint = 0, grp_covered = 1,
grp_unscalarizable_region = 0, grp_unscalarized_data = 0, grp_same_access_path
= 1, grp_partial_lhs = 0, grp_to_be_replaced = 1, grp_to_be_debug_replaced = 0}

but somehow it does not create an access for

  _1 = BIT_FIELD_REF <f[1][6], 32, 0>;
  _2 = (unsigned int) _1;

note the real offender here is (again) optimize_bit_field_compare ...

^ permalink raw reply	[flat|nested] 4+ messages in thread

* [Bug middle-end/107047] load introduced of struct fields after assigning it to a local variable
  2022-09-27  7:25 [Bug rtl-optimization/107047] New: load introduced of struct fields after assigning it to a local variable absoler at smail dot nju.edu.cn
  2022-09-27  9:10 ` [Bug middle-end/107047] " rguenth at gcc dot gnu.org
@ 2022-10-05 20:02 ` pinskia at gcc dot gnu.org
  2022-10-26  8:31 ` [Bug middle-end/107047] load introduced of struct/union " absoler at smail dot nju.edu.cn
  2 siblings, 0 replies; 4+ messages in thread
From: pinskia at gcc dot gnu.org @ 2022-10-05 20:02 UTC (permalink / raw)
  To: gcc-bugs

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Assignee|unassigned at gcc dot gnu.org      |pinskia at gcc dot gnu.org
             Status|NEW                         |ASSIGNED

--- Comment #2 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Mine but for GCC 14.

^ permalink raw reply	[flat|nested] 4+ messages in thread

* [Bug middle-end/107047] load introduced of struct/union fields after assigning it to a local variable
  2022-09-27  7:25 [Bug rtl-optimization/107047] New: load introduced of struct fields after assigning it to a local variable absoler at smail dot nju.edu.cn
  2022-09-27  9:10 ` [Bug middle-end/107047] " rguenth at gcc dot gnu.org
  2022-10-05 20:02 ` pinskia at gcc dot gnu.org
@ 2022-10-26  8:31 ` absoler at smail dot nju.edu.cn
  2 siblings, 0 replies; 4+ messages in thread
From: absoler at smail dot nju.edu.cn @ 2022-10-26  8:31 UTC (permalink / raw)
  To: gcc-bugs

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

--- Comment #3 from absoler at smail dot nju.edu.cn ---
and for union there's similar behavior:

union U2 {
    long long  f0;
    unsigned short  f2;
    int  f4;
};

void  func_17(union U2  p_20);
void  func_1() {
    func_17(g_39[0]);
}

void func_17(union U2 e) {
  int *f = &g_30;
  if (e.f0 || e.f2)
    *f = e.f2;
}

are compiled with gcc-12.1 -O1 to:

0000000000402020 <func_1>:
func_17():
/home/csmith-2.3.0/test/output2.c:87
  402020:       48 83 3d 68 3e 00 00    cmpq   $0x0,0x3e68(%rip)        #
405e90 <g_39>
  402027:       00 
  402028:       74 0d                   je     402037 <func_1+0x17>
/home/csmith-2.3.0/test/output2.c:88
  40202a:       0f b7 05 5f 3e 00 00    movzwl 0x3e5f(%rip),%eax        #
405e90 <g_39>
  402031:       89 05 71 3e 00 00       mov    %eax,0x3e71(%rip)        #
405ea8 <g_30>

uses of e.f0 and e.f2 are replaced by g_39[0]

^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2022-10-26  8:31 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-09-27  7:25 [Bug rtl-optimization/107047] New: load introduced of struct fields after assigning it to a local variable absoler at smail dot nju.edu.cn
2022-09-27  9:10 ` [Bug middle-end/107047] " rguenth at gcc dot gnu.org
2022-10-05 20:02 ` pinskia at gcc dot gnu.org
2022-10-26  8:31 ` [Bug middle-end/107047] load introduced of struct/union " absoler at smail dot nju.edu.cn

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).