https://bugs.kde.org/show_bug.cgi?id=386945
--- Comment #49 from Mark Wielaard <m...@klomp.org> --- We did discuss this a bit more on irc (#valgrind irc.freenode.net) and there are a couple more issues that need to be resolved to make all this work correctly. lxvd2x and lxvb16x have a similar issue where the load is split up in the frontend into smaller loads, which makes the partial-load-ok logic ineffective for memcheck. These also need to be rewritten to do full loads plus IR to manipulate the data so that memcheck can work effectively. The IRExpr_Load expression carries an IREndness expression the Endian-ness of the load, which should be helpful in the frontend to express some of these instructions. Unaligned (normal) load instructions do seem undefined. The power backend does seem to handle unaligned vector (128bit) loads (in VEX/priv/host_ppc_isel.c iselVecExpr_wrk), but not for non-vector loads. So given that unaligned loads are an issue, we need some solution for those (if ldbrx are ultimately translated into normal loads) in the ppc backend. memcheck mc_LOADVn_slow needs to be adapted to deal with unaligned loads (on ppc only?). And I assume mc_LOADV_128_or_256_slow would need something similar for unaligned vector loads (assuming lxvd2x and lxvb16x are allowed to do unaligned loads). There was also a question from the glibc hackers whether these vector instruction should be emitted at all given some power errata that talked about memory/cache corruption: https://gcc.gnu.org/ml/gcc/2018-12/msg00010.html but it looks like that is not a real concern, so we should act as if gcc will emit these instructions for new inlined str[n]cmp code. -- You are receiving this mail because: You are watching all bug changes.
