public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Marc Glisse <marc.glisse@inria.fr>
To: Joern Wolfgang Rennecke <gnu@amylaar.uk>
Cc: GCC Patches <gcc-patches@gcc.gnu.org>
Subject: Re: Simplify X * C1 == C2 with undefined overflow
Date: Fri, 7 Aug 2020 20:21:33 +0200 (CEST)	[thread overview]
Message-ID: <alpine.DEB.2.23.453.2008071939450.6903@stedding.saclay.inria.fr> (raw)
In-Reply-To: <5F2D51A5.3070006@amylaar.uk>

On Fri, 7 Aug 2020, Joern Wolfgang Rennecke wrote:

>> this transformation is quite straightforward, without overflow, 3*X==15 is
>> the same as X==5 and 3*X==5 cannot happen.
>
> Actually, with binary and decimal computers, this transformation (with 
> these specific numbers) is also valid for wrapping overflow.  More 
> generally, it is valid for wrapping overflow if the right hand side of 
> the comparison is divisible without rest by the constant factor, and the 
> constant factor has no sub-factor that is a zero divisor for the ring 
> defined by the wrapping operation. For binary computers, the latter 
> condition can be more simply be restated as: The constant factor has to 
> be odd. (For decimal computers, it's: must not be divisible by two 
> and/or five.)

If we are going to handle the wrapping case, we shouldn't limit to the 
non-wrapping meaning of multiplicity. 3*X==5 should become X==1431655767 
(for a 32 bit type), etc.

Do we have an extended gcd somewhere in gcc, to help compute 1431655767?

> (Even if the variable factor is wider than equality comparison, that is 
> not a problem as long as the comparison is not widened by the 
> transformation.)
>
> On the other hand, the following generalizations would work only without 
> overflow:
> - handling of inequality-comparisons - merely have to account for the sign of 
> the factor reversing the sense of
>  the inequality, e.g. -3*X >= 15 ---> X <= 5

And again for this one, we have to be careful how we round the division, 
but we don't have to limit to the case where 15 is a multiple of 3. 3*X>7 
can be replaced with X>2.


Those are two nice suggestions. Do you intend to write a patch? Otherwise 
I'll try to do it eventually (no promise).

-- 
Marc Glisse

  reply	other threads:[~2020-08-07 18:21 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-08-07 13:05 Joern Wolfgang Rennecke
2020-08-07 18:21 ` Marc Glisse [this message]
2020-08-07 20:30   ` Joern Wolfgang Rennecke
2020-08-07 20:57     ` Marc Glisse
2020-08-07 21:02       ` Jakub Jelinek
2020-08-07 21:36         ` Marc Glisse
2020-08-08  6:55           ` Jakub Jelinek
2020-08-07 21:58       ` Joern Wolfgang Rennecke
  -- strict thread matches above, loose matches on Subject: below --
2020-08-01  7:28 Marc Glisse
2020-08-03  8:51 ` Richard Biener
2020-08-04 15:38   ` Marc Glisse

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=alpine.DEB.2.23.453.2008071939450.6903@stedding.saclay.inria.fr \
    --to=marc.glisse@inria.fr \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=gnu@amylaar.uk \
    /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).