[Bug tree-optimization/32044] [4.3/4.4 Regression] final value replacement too aggressive for e.g. targets with no native div/mod insns

[rakdver at kam dot mff dot cuni dot cz]

------- Comment #61 from rakdver at kam dot mff dot cuni dot cz  2008-12-11 00:28 -------
Subject: Re:  [4.3/4.4 Regression] final value replacement too aggressive for
e.g. targets with no native div/mod insns

> Furthermore, if we want to generate the loop instead, are the alternatives
> you're considering sufficient to change code like:
> 
>   ... x / 45 ...
> 
> into the loop form?  

Although I think this is somewhat unrelated, we actually already do this
(see value-prof.c).

> The style:
> 
>   a = x / N;
>   b = x % N;
> 
> is pretty common; recognizing that pattern and generating a loop, or libcall to
> __aeabi_divmod, seems like a good thing.  One could argue that __aeabi_divmod
> itself should be responsible for noticing divisors that more profitably use
> repeated subtraction than other methods, on CPUs that don't have a hardware
> divide instruction.

The problem is that "profitably" depends on how large x is (i.e., using
the loop is only profitable when x is small).  As mentioned, we already
do the transformation in profile-driven optimizer, when we have this
information.

> Do we need a divmod optab?  Or, should we expect that if we provide an
> appropriate pattern in the ARM back end, combine will be able to smush the
> division and remainder operations together?

I think it should be able to (IIRC, we do so on x86).

> I guess where I'm going with this line of thinking is to argue that the
> transformation to division is fine, and that we should treat that as canonical
> -- but that we need a way to change divisions into repeated divisions if
> appropriate.

Users usually use this pattern (division by repeated subtraction) only
if the result is small; so transforming to actual division makes the
code worse (and understandably, the user angry :-) Unless profiling is
used, compiler does not have enough information to determine which form
is better, so I think we should prefer to keep whatever form was
originally in the program.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32044