------- 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
