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

[Török Edwin]

On 2008-12-23 19:24, Chris Lattner wrote:
> On Dec 23, 2008, at 4:17 AM, Török Edwin wrote:
>   
>>> 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?
>>>       
>> I found 2 messages on comp.lang.c about this:
>> http://groups.google.com/group/comp.lang.c/msg/28fcc4a0e29e5339
>> http://groups.google.com/group/comp.lang.c/msg/786c9f1cb2e9b085
>>
>> "     /* or can probably use memcmp since in practice it will safely
>>       stop on or near null != nonnull and return nonmatch, but not
>>      AFAICT guaranteed, and being not str* may alarm some */
>>
>> You seem to be correct - "7.21.4.1 The memcmp function" doesn't  
>> require it
>> to stop as long as it ultimately returns the correct result - but  
>> it's in
>> the implementation's interests to make it as efficient as possible."
>>     
>
> Ok.  This means that it should be opt-in on a per-target basis.
>
>   
>>> It would
>>> also be interesting to look at the source for various memcmp
>>> implementations
>>>       
>> glibc:
>> However in memcmp_not_common_alignment:
>> /* memcmp_not_common_alignment -- Compare blocks at SRCP1 and SRCP2  
>> with LEN
>>   `op_t' objects (not LEN bytes!).  SRCP2 should be aligned for memory
>>   operations on `op_t', but SRCP1 *should be unaligned*.  */
>> switch (len % 4) {
>> case 2:
>>      a1 = ((op_t *) srcp1)[0];
>>      a2 = ((op_t *) srcp1)[1];
>> ...
>> }
>>
>> It does a 2-byte read on srcp1, which is unaligned, so I think it may
>> cross a page boundary if we aren't allowed to do 2-byte reads on all  
>> the
>> region we pass to memcmp.
>>     
>
> opt_t is 16-bits?  That is unfortunate, it means we can't do the  
> optimization on glibc. :(
>   

op_t is an unsigned long, so 64-bits on my platform, and not 16 ;)