Bug 371989

Summary:	PCMPISTRM $0x72 and PCMPISTRI $0x12 validity bit propagation is imprecise
Product:	[Developer tools] valgrind	Reporter:	Patrick J. LoPresti <lopresti>
Component:	memcheck	Assignee:	Julian Seward <jseward>
Status:	REPORTED ---
Severity:	normal
Priority:	NOR
Version First Reported In:	3.12 SVN
Target Milestone:	---
Platform:	Compiled Sources
OS:	Linux
Latest Commit:		Version Fixed/Implemented In:
Sentry Crash Report:
Attachments:	Test case illustrating pcmpistrm $0x72 validity bit propagation failure Test case illustrating pcmpistri $0x12 validity bit propagation failure

Description Patrick J. LoPresti 2016-11-02 18:51:42 UTC

Created attachment 101977 [details]
Test case illustrating pcmpistrm $0x72 validity bit propagation failure

(cf. bug 309921)

Well, here we go again...

The attached program uses inline assembly to do something similar to the Intel C compiler's optimized "strspn()" routine.

It would be easy for me to use a suppression rule for warnings from inside the routine. But as with this example, memcheck generates a warning *outside* of the vectorized function.

So, memcheck is tainting the return value of the function as undefined. But the result is actually perfectly well-defined thanks to (a) the memory alignment of the arguments and (b) the way PCMPISTRM ignores everything after the first null byte.

Comment 1 Patrick J. LoPresti 2016-11-02 18:55:28 UTC

Forgot to mention:

I believe this example should run without warnings when "--partial-loads-ok=yes --expensive-definedness-checks=yes" are specified to memcheck.

Comment 2 Patrick J. LoPresti 2016-11-02 21:41:24 UTC

A similar problem happens with Intel's optimized atoi() routine. Actually this is so similar that I believe these can probably be fixed together, so I am just adding the second test case to this bug report as another attachment.

The Intel atoi() code uses PCMPISTRI $0x12,... Once again the return value from the function is tainted as undefined, resulting in memcheck complaints every time the value is used.

Comment 3 Patrick J. LoPresti 2016-11-02 21:42:01 UTC

Created attachment 101986 [details]
Test case illustrating pcmpistri $0x12 validity bit propagation failure

Comment 4 Julian Seward 2016-11-25 12:33:39 UTC

I'd fix this, if I could think of a sane way to do so.  Alas ..

Comment 5 Patrick J. LoPresti 2016-12-08 00:44:13 UTC

Just a thought... How about adding VEX opcodes corresponding to these string instructions?

Although the behavior of these instructions is (ludicrously) complex, the data flow is pretty simple: Two vectors of input; one vector and a few condition codes of output; every byte past the first zero ignored.

It seems to me that it should be pretty straightforward to do the memcheck instrumentation directly for most (all?) of the PCMPxSTRx variants.

Intel has had a few instruction set iterations (AVX2/AVX512/BMI/etc.) and they have not added any more monstrosities like these, so I do not think this would be entering an endless rat hole.

What do you think?