(I realize I did not answer the other ones)
Le 08/01/2011 11:06, Aneesh V a écrit :
>> Out of curiosity, can you elaborate on why the compiler would optimize
>> better in these cases?
>
> While counting down the termination condition check is against 0. So
> you can just decrement the loop count using a 'subs' and do a 'bne'.
> When you count up you have to do a comparison with a non-zero value. So
> you will need one 'cmp' instruction extra:-)
I would not try to be too smart about what instructions are generated
and how by a compiler such as gcc which has rather complex code
generation optimizations.
> bigger loop inside because that reduces the frequency at which your
> outer parameter changes and hence the overall number of instructions
> executed. Consider this:
> 1. We encode both the loop counts along with other data into a register
> that is finally written to CP15 register.
> 2. outer loop has the code for shifting and ORing the outer variable to
> this register.
> 3. Inner loop has the code for shifting and ORing the inner variable.
> Step (3) has to be executed 'way x set' number of times anyways.
> But having bigger loop inside makes sure that 2 is executed fewer times!
Here too it seems like you're underestimating the compiler's optimizing
capabilities -- your explanation seems to amount to extracting a
constant calculation from a loop, something that is rather usual in code
optimizing.
> With these tweaks the assembly code generated by this C code is as good
> as the original hand-written assembly code with my compiler.
How about other compilers?
>>> + for (way = num_ways - 1; way>= 0 ; way--)
>>> + for (set = num_sets - 1; set>= 0; set--) {
>>
>> Please fix whitespacing around operators. The best way to ''catch'em
>> all'' is to run Linux' checkpatch.pl (I do this with option --no-tree)
>> on all patches that you submit to u-boot and, fix all warning and errors
>> and if some are left that you think should not be fixed, mention them
>> and explain why they're wrongly emitted.
>
> I religiously do checkpatch whenever I send out a patch. Please note
> that my original mail seems to be fine. I saved it and ran checkpatch
> again. No errors, no warnings! Something amiss?
Well, something like "set>= 0" is quite surprising as it has
inconsistent spacing around a binary operators. But you're right,
checkpatch does not detect it. Can you fix them manually?
> Best regards,
> Aneesh
Amicalement,
--
Albert.
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
