public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
From: "joseph at codesourcery dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c/67999] Wrong optimization of pointer comparisons
Date: Wed, 28 Oct 2015 00:12:00 -0000 [thread overview]
Message-ID: <bug-67999-4-Vmgk1UyinN@http.gcc.gnu.org/bugzilla/> (raw)
In-Reply-To: <bug-67999-4@http.gcc.gnu.org/bugzilla/>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67999
--- Comment #22 from joseph at codesourcery dot com <joseph at codesourcery dot com> ---
On Tue, 27 Oct 2015, ch3root at openwall dot com wrote:
> What is missing in the discussion is a cost of support in gcc of objects
> with size > PTRDIFF_MAX. I guess overhead in compiled code would be
> minimal while headache in gcc itself is noticable. But I could be wrong.
I think the biggest overhead would include that every single pointer
subtraction, where the target type is (or might be, in the case or VLAs)
larger than one byte, would either need to have conditional code for what
order the pointers are in, or would need to extend to a wider type,
subtract in that type, divide in that type and then reduce to ptrdiff_t;
it would no longer be possible to do (ptrdiff_t subtraction, then
EXACT_DIV_EXPR on ptrdiff_t). There would be other things, such as
pointer addition / subtraction of integers needing to handle values
outside the range of ptrdiff_t, but it's pointer subtraction that I expect
would have the main runtime overhead.
(On strict alignment targets, for naturally-aligned power-of-two element
sizes, you could do logical shifts on the pointers before doing a signed
subtraction, so that case needn't be quite as inefficient as the general
case.)
next prev parent reply other threads:[~2015-10-28 0:12 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <bug-67999-4@http.gcc.gnu.org/bugzilla/>
2015-10-17 8:03 ` glisse at gcc dot gnu.org
2015-10-17 8:14 ` pinskia at gcc dot gnu.org
2015-10-17 8:35 ` schwab@linux-m68k.org
2015-10-17 12:52 ` ch3root at openwall dot com
2015-10-19 2:30 ` danielmicay at gmail dot com
2015-10-19 5:36 ` bugdal at aerifal dot cx
2015-10-19 8:17 ` fw at gcc dot gnu.org
2015-10-19 8:26 ` fw at gcc dot gnu.org
2015-10-19 8:41 ` danielmicay at gmail dot com
2015-10-19 8:47 ` danielmicay at gmail dot com
2015-10-19 9:05 ` fw at gcc dot gnu.org
2015-10-19 9:09 ` fw at gcc dot gnu.org
2015-10-19 9:12 ` danielmicay at gmail dot com
2015-10-19 9:26 ` danielmicay at gmail dot com
2015-10-19 9:55 ` danielmicay at gmail dot com
2015-10-19 9:56 ` rguenth at gcc dot gnu.org
2015-10-19 10:12 ` jakub at gcc dot gnu.org
2015-10-21 2:09 ` ch3root at openwall dot com
2015-10-21 2:18 ` ch3root at openwall dot com
2015-10-21 3:21 ` danielmicay at gmail dot com
2015-10-28 0:12 ` joseph at codesourcery dot com [this message]
2015-10-28 0:20 ` bugdal at aerifal dot cx
2015-10-28 2:29 ` joseph at codesourcery dot com
2015-10-28 18:26 ` ch3root at openwall dot com
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-67999-4-Vmgk1UyinN@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).