[llvm-commits] [llvm] r61297 - in /llvm/trunk: lib/Transforms/Scalar/SimplifyLibCalls.cpp test/Transforms/SimplifyLibCalls/2008-12-20-StrcmpMemcmp.ll

[Chris Lattner]

On Dec 22, 2008, at 7:15 AM, Török Edwin wrote:
>>> You need to check the alignment.
>> I think something like:
>> MinAlignStr = Minimum Alignment of Str1P, Str2P (max 16)
>> MinLen = Minimum length of Str1P and Str2P
>> AlignMinLen = AlignOf(MinLen) (max 16)
>> If (MinAlignStr >= AlingMinLen) -> transform is safe
>>
>
> But try this with llvm-gcc:
> #include <string.h>
> int foo(const char *s)
> {
>    return !memcmp(s,"x",2);
> }
>
> It produces:
> foo:
> .Leh_func_begin1:
> .Llabel1:
>    cmpw    $120, (%rdi)
>    sete    %al
>    movzbl    %al, %eax
>    ret
>
> So is it a bug in MemCmp optimization?

hi Edwin,

This is a really important question that I don't know the answer to.   
My understanding is that memcmp only touches the bytes necessary to  
make a decision: it is not allowed to touch the full size if  
unneeded.  However, I don't really *know* that, and nothing I find  
online in a quick scan comes up with an obvious answer.

Can you try asking on comp.lang.c or something like that?  It would  
also be interesting to look at the source for various memcmp  
implementations to decide if they are safe on commonly available  
systems (worst-case this becomes a target-specific optimization).

For example, darwin/ppc contains this comment:

// We optimize the compare by doing it word parallel.  This introduces
// a complication: if we blindly did word loads from both sides until
// finding a difference, we might get a spurious page fault by
// reading bytes past the difference.  To avoid this, we never do a  
"lwz"
// that crosses a page boundary.

Darwin/x86 has a similar comment.  This implies that the strcmp- 
 >memcmp optimization is legal (on darwin at least!), but that  
"unaligned memcmp" -> i16 load is not (and should be fixed!).

-Chris