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.
next prev 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: linkBe 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).