(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:
- 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,