[llvm-dev] Reliably mapping memcpy intrinsic

Hiroshi Yamauchi via llvm-dev llvm-dev at lists.llvm.org
Tue Mar 31 09:04:24 PDT 2020


Matt, sorry, no idea.

On Mon, Mar 30, 2020 at 4:09 PM Matt Fysh <mattfysh at gmail.com> wrote:

> Cool, - thanks Hiroshi! I gave it a try, however I'm finding that after
> setting to zero, it fails when trying to build a particular file
> (locale.cpp from libc++):
> https://github.com/llvm/llvm-project/blob/master/libcxx/src/locale.cpp
>
> Any ideas why that might be?
>
> Thanks again,
> matt.
>
> On Tue, 31 Mar 2020 at 02:41, Hiroshi Yamauchi <yamauchi at google.com>
> wrote:
>
>> I think setting MaxStoresPerMemcpy to zero (eg.
>> lib/Target/X86/X86ISelLowering.cpp) may do the trick. As it does not
>> seem to be a flag, it would require a source edit.
>>
>>
>>
>> On Fri, Mar 27, 2020 at 9:26 AM Matt Fysh via llvm-dev <
>> llvm-dev at lists.llvm.org> wrote:
>>
>>> Similar to how `operator new(size)` can be overridden during linking, to
>>> capture and customize all memory allocation operations, I'd like to be able
>>> to capture all scenarios where memory is copied or moved. I've tried to use
>>> `--wrap memcpy` with some success, however I've noticed that in some
>>> instances (e.g. copying a small struct) the memcpy instruction in the IR is
>>> replaced with a sequence of movq instructions, and the wrap function is not
>>> able to hook into that piece of the code.
>>>
>>> Is there a way to ensure all llvm.memcpy intrinsics in the IR are always
>>> lowered to call the memcpy symbol?
>>>
>>> Failing that approach, can you suggest other ways to plug into the
>>> desired memory options? I'd like to hook into every memory operation that
>>> has a source and a destination address (copy, move, etc) so I can trace the
>>> passage of symbols through an executing program.
>>>
>>> Thankyou
>>> _______________________________________________
>>> LLVM Developers mailing list
>>> llvm-dev at lists.llvm.org
>>> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200331/7af99f85/attachment-0001.html>


More information about the llvm-dev mailing list