[PATCH] Optimize SSE 4.1 x86_64 memcmp

[Joseph S. Myers]

On Mon, 3 Feb 2014, Florian Weimer wrote:

> One thing I would like to get consensus on eventually is whether future
> implementations of memcmp must not behave as a timing oracle.  (There might be

I don't understand what your proposed requirement is - I certainly expect 
memcmp to be faster for differences in the first byte than for differences 
at the millionth byte, for example.  Are you saying that if the difference 
is in a given aligned 8-byte block then the timing shouldn't indicate 
where in that block the difference is, or something like that?

I don't believe specific timing properties are part of the expected 
interface to memcmp.

> architectures where achieving this has a run-time cost.)  If we are unwilling
> to make this promise, the oracle-free version would have to be conditional on
> _FORTIFY_SOURCE.

I don't think this is anything to do with _FORTIFY_SOURCE, which is about 
detecting some uses of functions that involve undefined behavior at C 
level, and bounding the effects of that undefined behavior by terminating 
the program.  It sounds to me more like a separate function at the C API 
level, much like memset_s in C11 Annex K (memset required not to be 
optimized away, for clearing memory that may contain sensitive data).

-- 
Joseph S. Myers
joseph@codesourcery.com