"Babic, Nedeljko" <nba...@mips.com> writes: >> I notice that the patches are very large. Even though the parts they >> contain are related, the sheer size makes them difficult to evaluate as >> review effort grows more than linearly with patch size. So if you could >> split them into smaller parts that would reduce the effort to review and >> integrate your patches considerably. >> > > Ok. I will try to send smaller patches in the future. > Do you want me to split patches that are already submitted?
That would be appreciated. Especially splitting out preparatory changes (e.g. refactoring) eases review greatly. >> All your optimizations are done as inline assembly. Our experience with >> inline assembly is mixed at best. In most cases, it creates portability >> problems and performance is reduced. As we strive to support ever more >> systems and compilers, inline assembly is less than ideal. >> >> What motivated your decision to implement your optimizations that way? >> >> best regards, Diego > > Our optimizations are targeting mainly parts of the code that compiler cannot > deal with good enough. For the rest of the code compilers for MIPS are > doing pretty good job in optimizing it. This leads to faster development > and we don't loose on performance. > > Also, if the function is written in external asm, the compiler will not > inline it and for small functions that are called lots of times this > could lead to significant performance drop. Most, if not all, of the functions in your patches are large and the call overhead would be insignificant. Some of them are even called through function pointers, so inling cannot possibly happen. > Code written in external assembler for one ABI basically cannot be used > on systems with different ABI without changes. Code written in inline > assembly can. These are all leaf functions, so ABI concerns are minimal. Any differences that affect the code can be easily dealt with. We already do this for other architectures. > And finally, it is easier to maintain the code with inline assembly than > the code with external assembly. That is simply not true. -- Måns Rullgård m...@mansr.com _______________________________________________ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
