Many thanks for your prompt and detailed reviews, Maciej, > > The exact NOP placements in this patch are provisional. Request for comment > > on the method to use. I believe there are at least three alternatives: > > > > 1. Add #ifdefs or macros in the source code (similar to this patch). > > 2. Modify the assembler to automatically insert NOPs as required. > > 3. Avoid assembly and use C versions of memcpy etc. instead. > > > > This change has been ported from v2.6 patches. > > I can't tell if this is a porting artefact or whether the reason is > different, but many of these loops contain more than 6 instructions > already, or need fewer than 3 NOPs. Please review accordingly. > > Also can't this be handled automagically by GAS instead? We have similar > workarounds already implemented, see e.g. `-mfix-vr4130'. Otherwise this > is looking to me like a candidate for a maintenance nightmare (which the > problem with getting loop instruction counts wrong in your patch is a sign > of). As noted above, please ignore the NOP details which just barely survived from v2.6 (according to the principle that too many NOPs still work, whereas too few crash badly), especially since I very much agree with you that it is unreasonable to maintain such NOPs by hand and would rather proceed with alternative (2) [from the list above] that is to modify the assembler instead. Meanwhile, is it possible to run with alternative (3) that is to use C fallbacks for the R5900, provided the performance penalty is reasonable? Fredrik
