On Mon, 1 Oct 2018, Richard Biener wrote:
On Sat, Sep 29, 2018 at 1:35 PM Marc Glisse <marc.gli...@inria.fr> wrote:
Hello,
I noticed quite ugly code from both testcases. This transformation does
not fix either, but it helps a bit.
I'm curious why you chose to restrict to INTEGER_CST A and B?
Is that because of the case when (X / [ex] A) +- B evaluates to zero
but A * B overflows? Can that ever happen? Isn't it enough to know
that A isn't -1? That is, can we use expr_not_equal_to or friends
to put constraints on possibly non-constant A/B?
For A, I don't remember seeing a divexact with non-constant denominator in
gcc. For B, constants are what I was seeing in testcases, I was even
tempted to implement it only for B==1 which is simpler.
At first, I only had the version without casts, and for that I needed to
be able to check for overflow, so constants. Now that I have a version
that casts to unsigned, it would be valid with arbitrary A and B indeed.
There are also a lot of casts making my head hurt (we may need one more
for the last @1 if it isn't a constant anymore).
I was also thinking of things like ((X/[ex]3)+1)*6, but that doesn't occur
as often.
Otherwise the patch is of course OK and the above would just improve
it.
I'll commit it and see if I can find some time...
--
Marc Glisse
