On 20 April 2006 18:28, Kimmo Fredriksson wrote:
> On Thu, 20 Apr 2006, Dave Korn wrote:
>
>>
>> Hello, gcc-hackers!
>>
>> This is somewhat chopped-down from the original code it began life as, but
>> it serves to illustrate the point.
>>
>> unsigned int PhyFrameConfig (unsigned int channelPrf, unsigned int bpp,
>> unsigned int bufferSize) {
>> unsigned int prfShift;
>> unsigned int symbolOffset;
>> unsigned int symbolShift;
>> unsigned int config;
>>
>> switch (channelPrf)
>> {
>> case (0):
>> prfShift = 0;
>> symbolOffset = ((32) * 1) / (1 << bpp);
>> break;
>
> Why not:
>
> symbolOffset = ((32) * 1) >> bpp;
>
> ?
>
> K
Um, because I want the *compiler* to do that for me, and because I think it
ought to be able to, and because sometimes it does and sometimes it doesn't,
seemingly dependent on whether bpp is a known constant or not, and I'm not
sure why, since ISTM that it ought to be a valid transformation for unknown
values of bpp too. Please remember:
>> This is somewhat chopped-down from the original code it began life as, but
>> it serves to illustrate the point.
and:
>> right-shifts by (bpp) bits instead. (Actually, to be completely accurate,
>> in my original case I have (2 << bpp) and want to right-shift by (bpp+1)
>> bits, but I'll start with the simpler case first).
and so what I need to work out before I implement such an optimisation is:
>> Is there some corner case / overflow / other catch that I just can't see
>> that makes this an invalid case? Is it just the worry about silly values
>> of bpp that prevents this optimisation being allowed? It would be fine if
>> bpp was a known constant; why is it not fine if bpp is an unknown constant?
I guess I should consider filing it as a missed-optimisation-opportunity
bug, and maybe see if it's still present in mainline or only on 3.3 series
where I spotted it.
cheers,
DaveK
--
Can't think of a witty .sigline today....
