<html> <head> <base href="https://bugs.freedesktop.org/"> </head> <body> <div> <a class="bz_bug_link bz_status_NEW " title="NEW - Provide option for llvmpipe JIT code to run cleanly under valgrind" href="https://bugs.freedesktop.org/show_bug.cgi?id=99527#c2">Comment # 2</a> on <a class="bz_bug_link bz_status_NEW " title="NEW - Provide option for llvmpipe JIT code to run cleanly under valgrind" href="https://bugs.freedesktop.org/show_bug.cgi?id=99527">bug 99527</a> from <a class="email" href="mailto:jfonseca@vmware.com" title="Jose Fonseca <jfonseca@vmware.com>"> Jose Fonseca</a> <pre>I agree with Roland. I wouldn't oppose patches fixing these (including --enable-valgrind build option if performance suffered). But it won't be trivial. A big source of issues is the fact that we need padding to fill the SIMD instructions lanes. That is, we might need to process 3 floats, but then we allocate tempoary variables worth of 8 floats, where the last 5 are unitizialied garbagge. It's not hard to fix this, but there are hundreds of places this happens. I suspect that in many cases are actually false positives, ie, limitatio in valgrind analysis: we use uninitialize memory for temporary calculations, but they are soon discarded. How about `--suppressions` option? For llvmpipe there doesn't seem to be many different stack traces. Another option is to use call VALGRIND_DISABLE_ERROR_REPORTING / VALGRIND_ENABLE_ERROR_REPORTING before/after JIT code. Feel free to experiment with any of the above FWIW.</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are the assignee for the bug.</li> <li>You are the QA Contact for the bug.</li> </ul> </body> </html>