[LLVMdev] How to prevent insertion of memcpy()

[Chandler Carruth]

On Tue, May 29, 2012 at 11:14 AM, Chandler Carruth <chandlerc at google.com>wrote:

> On Tue, May 29, 2012 at 11:11 AM, Jeffrey Yasskin <jyasskin at googlers.com>wrote:
>
>> On Tue, May 29, 2012 at 10:50 AM, Chandler Carruth <chandlerc at google.com>
>> wrote:
>> > On Tue, May 29, 2012 at 10:46 AM, Dmitry Vyukov <dvyukov at google.com>
>> wrote:
>> >>
>> >> On Tue, May 29, 2012 at 9:40 PM, Chandler Carruth <
>> chandlerc at google.com>
>> >> wrote:
>> >>>>>>>
>> >>>>>>> > How do I disable that feature? I've tried -fno-builtin and/or
>> >>>>>>> > -ffreestanding
>> >>>>>>> > with no success.
>> >>>>>>> clang (as well as gcc) requires that freestanding environment
>> >>>>>>> provides
>> >>>>>>> memcpy, memmove, memset and memcmp.
>> >>>>>>>
>> >>>>>>> PS: Consider emailing cfedev, not llvmdev.
>> >>>>>>
>> >>>>>>
>> >>>>>> Hi,
>> >>>>>>
>> >>>>>> Thanks. I've emailed cfe-dev.
>> >>>>>> We absolutely need clang/llvm to not insert the calls into our
>> code.
>> >>>>>
>> >>>>>
>> >>>>> This really isn't possible.
>> >>>>>
>> >>>>> The C++ standard essentially requires the compiler to insert calls
>> to
>> >>>>> memcpy for certain code patterns.
>> >>>>>
>> >>>>> What do you really need here? Clearly you have some way of handling
>> >>>>> when the user writes memcpy; what is different about Clang or LLVM
>> inserting
>> >>>>> memcpy?
>> >>>>
>> >>>>
>> >>>> I need it for ThreadSanitizer runtime. In particular
>> >>>>
>> >>>>
>> http://llvm.org/viewvc/llvm-project/compiler-rt/trunk/lib/tsan/rtl/tsan_interceptors.cc?view=annotate
>> >>>> line 1238. But I had similar problems in other places.
>> >>>> Both memory access processing and signal handling are quite tricky,
>> we
>> >>>> can't allow recursion.
>> >>>
>> >>>
>> >>> The first thing to think about is that you *do* need to use
>> -fno-builtin
>> >>> / -ffreestanding when compiling the runtime because it provides its
>> own
>> >>> implementations of memcpy.
>> >>
>> >>
>> >> We used both at some points in time, but the problem is that they do
>> not
>> >> help to solve the problem. I think we use -fno-builtin now, I am not
>> sure
>> >> about -ffreestanding.
>> >>
>> >>> The second is that there is no way to write fully generic C++ code w/o
>> >>> inserting calls to memcpy. =/ If you are writing your memcpy
>> implementation,
>> >>> you'll have to go to great lengths to use C constructs that are
>> guaranteed
>> >>> to not cause this behavior, or to manually call an un-instrumented
>> memcpy
>> >>> implementation. I don't know of any easy ways around this.
>> >>
>> >>
>> >> What are these magic constructs. I had problems with both struct copies
>> >> and for loops.
>> >
>> >
>> > Don't copy things by value ever. =/ It is really, *really* hard to do
>> this.
>> > If at all possible, I would build your runtime against an
>> un-instrumented
>> > memcpy (perhaps defined within the runtime), and then use aliases or
>> other
>> > techniques to wrap the instrumented functions in the exported names
>> > necessary for use when intercepting memcpy calls from the instrumented
>> > program.
>>
>> There are some other platforms that absolutely can't tolerate function
>> calls. Do they have an attribute or pass to tell LLVM to inline any
>> functions it or clang inserts? Could Dmitry do the same thing?
>>
>
> Yes, there are attributes which can be attached to the non-instrumented
> memcpy function, provided by the runtime and selected due to
> -ffreestanding, which will force inlining. __attribute__((always_inline)),
> __attribute__((flatten)). I suspect we don't correctly support the latter
> in Clang/LLVM, but that's clearly a missing feature we should fix.
>

But to harp on it a bit because this is on 'llvmdev' and is of general
interest: please don't use these to fix *performance* problems without
first filing a bug against LLVM's optimizers for why it was necessary. In
an ideal world these should only be used where there is a
platform/ABI/debugging/etc contract that no function calls occur.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20120529/9e6133ff/attachment.html>