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 -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200327/f2f91059/attachment.html>
Hiroshi Yamauchi via llvm-dev
2020-Mar-30 15:41 UTC
[llvm-dev] Reliably mapping memcpy intrinsic
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/20200330/b0467bbf/attachment-0001.html>
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/6d78102d/attachment-0001.html>