public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
From: "hubicka at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug tree-optimization/95663] static_cast checks for null even when the pointer is dereferenced
Date: Mon, 13 Dec 2021 11:10:53 +0000	[thread overview]
Message-ID: <bug-95663-4-l8hghx0277@http.gcc.gnu.org/bugzilla/> (raw)
In-Reply-To: <bug-95663-4@http.gcc.gnu.org/bugzilla/>

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

--- Comment #20 from Jan Hubicka <hubicka at gcc dot gnu.org> ---
I really think with -fdelete-null-pointer-checks we should optimize away the
pointer adjustment relying on the fact that program will segfault.

I was wondering, -fdelete-null-pointer-checks currently requires pointer to be
precisely 0.  We are already iffy here since the access is at non-0 offset, but
since infer_nonnull_range_by_dereference uses check_loadstore:

static bool
check_loadstore (gimple *, tree op, tree, void *data)
{
  if (TREE_CODE (op) == MEM_REF || TREE_CODE (op) == TARGET_MEM_REF)
    {
      /* Some address spaces may legitimately dereference zero.  */
      addr_space_t as = TYPE_ADDR_SPACE (TREE_TYPE (op));
      if (targetm.addr_space.zero_address_valid (as))
        return false;

      return operand_equal_p (TREE_OPERAND (op, 0), (tree)data, 0);
    }
  return false;
}

which completely ignores MEM_REF_OFFSET we actually turn into trap accesses
that are arbitrarily far from NULL.  We also ignore handled components so we
miss this for example for variable array accesses I think.

However if we had --param null-pointer-zone defaulting to say 4k (a page size)
we could optimize all accesses that are near the NULL pointer.  This would let
us to optimize this correctly and also i.e. simplify ipa-pta that currently
special cases 0 as null but thinks that any other constat may point to any
global variable.  Small constants are common so this should optimize
noticeably.

For clang binary there are really many traps added by this logic that makes
code noticeably uglier than what clang generates on its own sources.

  parent reply	other threads:[~2021-12-13 11:10 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-06-13 10:52 [Bug c++/95663] New: " jzwinck at gmail dot com
2020-06-15  6:47 ` [Bug tree-optimization/95663] " rguenth at gcc dot gnu.org
2020-06-15 10:04 ` redi at gcc dot gnu.org
2020-06-15 10:09 ` redi at gcc dot gnu.org
2020-06-15 11:46 ` jzwinck at gmail dot com
2020-06-15 12:50 ` rguenther at suse dot de
2020-06-15 12:53 ` redi at gcc dot gnu.org
2020-06-15 12:54 ` redi at gcc dot gnu.org
2020-06-15 13:03 ` rguenther at suse dot de
2020-06-15 13:32 ` jakub at gcc dot gnu.org
2020-06-26 22:18 ` law at redhat dot com
2020-06-27  0:20 ` jzwinck at gmail dot com
2020-06-27 11:49 ` glisse at gcc dot gnu.org
2020-06-27 15:36 ` law at redhat dot com
2020-06-27 15:40 ` law at redhat dot com
2020-06-27 15:57 ` jakub at gcc dot gnu.org
2021-01-07 13:13 ` redi at gcc dot gnu.org
2021-01-07 13:14 ` redi at gcc dot gnu.org
2021-01-07 20:00 ` law at redhat dot com
2021-12-13 11:05 ` hubicka at gcc dot gnu.org
2021-12-13 11:10 ` hubicka at gcc dot gnu.org [this message]
2021-12-13 15:51 ` law at gcc dot gnu.org
2022-01-03  9:54 ` rguenther at suse dot de

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-95663-4-l8hghx0277@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).