public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
From: "rguenth at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug tree-optimization/102448] [12 Regression] wrong codegen in gcc in spec2017 since 24f99147b9264f8f7d9cfb2fa6bd431edfa252d2
Date: Thu, 23 Sep 2021 08:11:25 +0000	[thread overview]
Message-ID: <bug-102448-4-UtwVpTwgG4@http.gcc.gnu.org/bugzilla/> (raw)
In-Reply-To: <bug-102448-4@http.gcc.gnu.org/bugzilla/>

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

--- Comment #5 from Richard Biener <rguenth at gcc dot gnu.org> ---
  <bb 276> [local count: 5160403229]:
  # ivtmp.589_349 = PHI <ivtmp.589_627(276), ivtmp.589_618(275)>
  _903 = (void *) ivtmp.589_349;
  [ira-costs.c:1641:24] MEM <vector(4) int> [(int *)_903] = { 1000000, 1000000,
1000000, 1000000 };
  ivtmp.589_627 = ivtmp.589_349 + 16;
  goto <bb 276>; [100.00%]

that's an endless loop...

but nothing wrong in .vect:

  if (_475 <= 2)
    goto <bb 402>; [10.00%]
  else
    goto <bb 397>; [90.00%]

  <bb 397> [local count: 860067200]:
  # RANGE [1, 1073741823] NONZERO 1073741823
  bnd.549_503 = niters.548_402 >> 2;
  vect_cst__537 = { 1000000, 1000000, 1000000, 1000000 };
  # PT = null { D.10048 } (escaped, escaped heap)
  # ALIGN = 8, MISALIGN = 0
  vectp_newmem.553_545 = newmem_696 + 4;

  <bb 265> [local count: 5160403229]:
  # RANGE [0, 2147483647] NONZERO 2147483647
  # i_395 = PHI <[ira-costs.c:1640:47] i_23(312), [ira-costs.c:1640:10] 0(397)>
  # PT = null { D.10048 } (escaped, escaped heap)
  # ALIGN = 4, MISALIGN = 0
  # vectp_newmem.552_559 = PHI <vectp_newmem.552_560(312),
vectp_newmem.553_545(397)>
  # ivtmp_572 = PHI <ivtmp_587(312), 0(397)>
  [ira-costs.c:1641:24] MEM <vector(4) int> [(int *)vectp_newmem.552_559] =
vect_cst__537;
  [ira-costs.c:1640:47] # RANGE [1, 2147483647] NONZERO 2147483647
  i_23 = i_395 + 1;
  [ira-costs.c:1640:17] # PT = null { D.10048 } (escaped, escaped heap)
  # ALIGN = 8, MISALIGN = 0
  vectp_newmem.552_560 = vectp_newmem.552_559 + 16;
  [ira-costs.c:1640:17] ivtmp_587 = ivtmp_572 + 1;
  if (ivtmp_587 < bnd.549_503)
    goto <bb 312>; [83.33%]
  else
    goto <bb 399>; [16.67%]

  <bb 312> [local count: 4300336028]:
  goto <bb 265>; [100.00%]

in IVOPTs we have

  <bb 265> [local count: 5160403229]:
  # ivtmp.589_349 = PHI <ivtmp.589_627(312), ivtmp.589_618(397)>
  # PT = null { D.10048 } (escaped, escaped heap)
  _903 = (void *) ivtmp.589_349;
  [ira-costs.c:1641:24] MEM <vector(4) int> [(int *)_903] = { 1000000, 1000000,
1000000, 1000000 };
  ivtmp.589_627 = ivtmp.589_349 + 16;
  if (ivtmp.589_627 != _914)
    goto <bb 312>; [83.33%]
  else
    goto <bb 399>; [16.67%]

but then CCP concludes the test is never false.

Visiting statement:
_914 = _398 + _935;
which is likely CONSTANT
Lattice value changed to CONSTANT 0x4 (0xfffffffffffffff8).  Adding SSA edges
to worklist.
marking stmt to be not simulated again
Adding destination of edge (282 -> 283) to worklist

...

Simulating block 283

Visiting PHI node: ivtmp.589_349 = PHI <ivtmp.589_627(283), ivtmp.589_618(282)>
        Argument #0 (283 -> 283 not executable)
        Argument #1 (282 -> 283 executable)
        ivtmp.589_618   Value: CONSTANT 0x0 (0xfffffffffffffff8)

    PHI node value: CONSTANT 0x0 (0xfffffffffffffff8)

Lattice value changed to CONSTANT 0x0 (0xfffffffffffffff8).  Adding SSA edges
to worklist.

Visiting statement:
# PT = null { D.10048 } (escaped, escaped heap)
_903 = (void *) ivtmp.589_349;
which is likely CONSTANT
Lattice value changed to CONSTANT 0x0 (0xfffffffffffffff8).  Adding SSA edges
to worklist.

Visiting statement:
ivtmp.589_627 = ivtmp.589_349 + 16;
which is likely CONSTANT
Lattice value changed to CONSTANT 0x0 (0xfffffffffffffff8).  Adding SSA edges
to worklist.

Visiting statement:
if (ivtmp.589_627 != _914)
which is likely CONSTANT
Adding destination of edge (283 -> 283) to worklist

Simulating block 283

Visiting PHI node: ivtmp.589_349 = PHI <ivtmp.589_627(283), ivtmp.589_618(282)>
        Argument #0 (283 -> 283 executable)
        ivtmp.589_627   Value: CONSTANT 0x0 (0xfffffffffffffff8)
        Argument #1 (282 -> 283 executable)
        ivtmp.589_618   Value: CONSTANT 0x0 (0xfffffffffffffff8)

    PHI node value: CONSTANT 0x0 (0xfffffffffffffff8)

so CCP knows that _627 is aligned to 8 but _914 has a bit 0x4 set.

What's wrong is

  # PT = { D.10048 } (escaped, escaped heap)
  # ALIGN = 8, MISALIGN = 0
  vectp_newmem.553_545 = newmem_696 + 4;

since newmem is aligned to 8, but here we offset it by 4.

It seems that DR_PTR_INFO cannot really be used to derive the alignment of
a pointer created from the access since it is the alignment of an SSA name
that's on the base of the ref which means that alignment info in this
does not reflect any constant or variable offset.

  parent reply	other threads:[~2021-09-23  8:11 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-09-22 12:07 [Bug tree-optimization/102448] New: " tnfchris at gcc dot gnu.org
2021-09-22 12:30 ` [Bug tree-optimization/102448] " rguenth at gcc dot gnu.org
2021-09-22 18:50 ` tnfchris at gcc dot gnu.org
2021-09-23  6:35 ` rguenth at gcc dot gnu.org
2021-09-23  6:54 ` rguenth at gcc dot gnu.org
2021-09-23  8:11 ` rguenth at gcc dot gnu.org [this message]
2021-09-23  9:17 ` cvs-commit at gcc dot gnu.org
2021-09-23  9:18 ` rguenth at gcc dot gnu.org
2021-09-23  9:21 ` tnfchris at gcc dot gnu.org

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=bug-102448-4-UtwVpTwgG4@http.gcc.gnu.org/bugzilla/ \
    --to=gcc-bugzilla@gcc.gnu.org \
    --cc=gcc-bugs@gcc.gnu.org \
    /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).