From mboxrd@z Thu Jan 1 00:00:00 1970 From: Albert ARIBAUD Date: Wed, 12 Jan 2011 20:18:15 +0100 Subject: [U-Boot] [PATCH 2/8] armv7: cache maintenance operations for armv7 In-Reply-To: <4D28373D.4000505@ti.com> References: <1293018898-13253-1-git-send-email-aneesh@ti.com> <1293018898-13253-3-git-send-email-aneesh@ti.com> <4D2805FC.7070200@free.fr> <4D28373D.4000505@ti.com> Message-ID: <4D2DFE77.8000104@free.fr> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de (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.