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