> > All these optimised, vectorised (effectively) string ops rely on two > > techniques: > > > > (1) using properties of carry-chain propagation in addition/subtraction > > so as find out whether any byte in a word is zero, and if so > > which one > > Do you mean the well know and widely use technique: [..]
Yes. > note that in GLIBC the even the default generic implementation strlen.c > uses this trick. Yes. So Memcheck intercepts strlen et al in glibc. > Yup. On processors with wide registers and multiple Load/Store and FixPoint > units it would criminally negligent not to do this. Also you will be see a > lot more speculative loads in both hand tuned code and with GCC-4.3 > (Auto-vectorization and auto-parallelization). This applies to POWER > (Altivec) and x86(_64) (SSE4). In hand tuned code, perhaps. I would be surprised to see overruns in autovectorised code, since compilers tend only to vectorise loops for which the trip count is known at run time before the loop starts, and so generate a vector loop and a following fixup loop to handle any leftover iterations. So the vector loop doesn't overrun memory. > > * do not strip all symbol names off ld.so > > This is not really our call! You are going after LOCAL symbols which are > only needed for debug (not needed at run-time). The distros can strip > libraries to save space on the ISO images, so they do. The one concession > they make is to provide the debug-info images. In the end I simply arranged for Memcheck on ppc32/64-linux to check for the presence of the relevant symbols in ld.so, and crap out if they are not present, printing a message advising the user to install the debuginfo image. J ------------------------------------------------------------------------- SF.Net email is sponsored by: The Future of Linux Business White Paper from Novell. From the desktop to the data center, Linux is going mainstream. Let it simplify your IT future. http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4 _______________________________________________ Valgrind-developers mailing list Valgrind-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-developers
