public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
From: Paul Schlie <schlie@comcast.net>
To: GCC Development <gcc@gcc.gnu.org>
Subject: potential simple loop optimization assistance strategy?
Date: Fri, 01 Jul 2005 15:51:00 -0000	[thread overview]
Message-ID: <BEEADEA6.AB11%schlie@comcast.net> (raw)

As in general it seems that as the compiler knows what it needs to know to
enable ideal loop optimization, why not simply have it assert: if it knew x,
then it could do y?  For example, if given something like:

  for (i = x; i < y; i++){ ... }

Where it may not be known statically if x < y, or what (y - x) % N may be;
therefore possibly difficult to ideally optimize.  Where then instead of
assuming something that may not be factual by default, it could generate a
warning indicating that the loop may be further optimized if it knew that
x < y, and/or (y - x) % N == 0.  Where then the programmer could then choose
to warrant it by preconditioning the loop:

  assert((x < y) && ((y - x) % 4)); // which could throw an exception.

  for ((i = x; i < y; i++){ ... }

Where although it would require run-time code, it's overhead should be
insignificant if the benefit of the optimization were truly significant;
thereby enabling the programmer to help the compiler help himself, without
the introducing potentially arbitrary behaviors, by explicitly trapping them
instead.

Where if the programmer didn't add an assertion, or explicitly enable a
potentially unsafe optimization, then the compiler should not presume
anything other than what it truly factually knows, which may include
optimizations based on whether the target traps or wraps overflow, etc.

(it may even be reasonable for the compiler to optionally insert run-time
assertions automatically to enable the deterministic trapping of conditions
which may be inconsistent with the optimizations assumptions?)


             reply	other threads:[~2005-07-01 15:51 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-07-01 15:51 Paul Schlie [this message]
2005-07-01 16:24 ` Gabriel Dos Reis
2005-07-01 17:15   ` Paul Schlie
2005-07-01 16:27 ` Devang Patel
2005-07-01 18:16 ` Giovanni Bajo
2005-07-01 18:22   ` Diego Novillo
2005-07-01 18:26     ` Giovanni Bajo
2005-07-01 19:42       ` Paul Schlie
     [not found]       ` <m3k6ka6po1.fsf@localhost.localdomain>
2005-07-02  9:18         ` Giovanni Bajo
2005-07-02 15:39           ` Michael Veksler
2005-07-02 18:58             ` Giovanni Bajo

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=BEEADEA6.AB11%schlie@comcast.net \
    --to=schlie@comcast.net \
    --cc=gcc@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).