[llvm-dev] Which assumptions do llvm.memcpy/memmove/memset.* make when the count is 0?

George Burgess IV via llvm-dev llvm-dev at lists.llvm.org
Thu Jul 20 23:27:35 PDT 2017


As of earlier this year, we now explicitly ignore the nonnull
attributes that glibc puts on memcpy (and other stdlib functions). I
don't know how LLVM feels about dangling or underaligned pointers in
particular, but AFAICT, we do try hard to make sure that
memcpy(NULL, _, 0) works as the user probably intends.

Here's the thread I read about it:
http://lists.llvm.org/pipermail/cfe-dev/2017-January/052066.html . As
I recall, the tl;dr was "optimizing these assumptions to death doesn't
realistically buy us much of anything, and there's a nontrivial amount
of real-world code that depends on this behavior."

On Thu, Jul 20, 2017 at 9:06 PM, John Regehr via llvm-dev
<llvm-dev at lists.llvm.org> wrote:
> Also note that whereas GCC exploits the tricky definition of memcpy(), LLVM
> at present doesn't appear to:
>
>   https://godbolt.org/g/8uxvBQ
>
> In fact LLVM doesn't even assume the pointer is non-null in a case where I'd
> argue that it should:
>
>   https://godbolt.org/g/svHQKL
>
> John
>
>
>
> On 07/20/2017 10:00 PM, John Regehr via llvm-dev wrote:
>>>
>>> So, the pointer arguments of memcpy *shall* (a violation of a shall
>>> clause is UB, per ยง4/2) have valid values, even though the function will
>>> copy zero characters.
>>
>>
>> This is true in C but the question was about LLVM intrinsics.
>>
>> Since the LangRef does not mention any such restriction, I would assume
>> that memcpy(0,0,0) is not UB in LLVM.  If it is UB then we must update the
>> LangRef to be clear on this point (actually we should update the LangRef
>> either way since this is a question that'll come up again).
>>
>> John
>>
>> _______________________________________________
>> LLVM Developers mailing list
>> llvm-dev at lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev


More information about the llvm-dev mailing list