[PATCH] D20148: Idea for avoiding memory allocation calls.

Sean Silva via llvm-commits llvm-commits at lists.llvm.org
Wed May 11 18:56:42 PDT 2016


On Wed, May 11, 2016 at 12:25 AM, Rong Xu <xur at google.com> wrote:

> xur added a comment.
>
> This avoids calloc in lprofCreateBufferIO() which is not used at all if
> there is not value profiles.
>
> But how about the malloc calls from  setFilenamePossiblyWithPid() and
> truncateCurrentFile(). They are not from value profiling, but they also
> call dynamic memory allocation.
>

I suspect some combination of luck and that we officially expose only a
limited API to users means we haven't hit those. This issue has only
recently reached our priority list and we'll be looking more deeply at the
issues and our requirements.


>
> Maybe we should convert all these into alloca or using pre-allocated
> memory.
>

I would prefer pre-allocated, but I suppose alloca is fine and avoids a
fixed limit. The downside of alloca is that in the worst case
circumstances, we can overflow the stack and trigger an issue that is
difficult to debug; at least for a fixed buffer we can return an error code.

>
> David and I are working on to get the profile runtime malloc free (or at
> least avoiding re-entrance to malloc) in the past few days. Hopefully we
> can have some discussion on this soon.
>

Great! Glad we are working in the same direction.

What do you mean "avoiding re-entrace to malloc"? Are you making calls into
the runtime lib from malloc? (for value profiling presumably? I would not
have guessed that malloc libs were using indirect calls)

-- Sean Silva


>
>
> Repository:
>   rL LLVM
>
> http://reviews.llvm.org/D20148
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20160511/80e9e01b/attachment.html>


More information about the llvm-commits mailing list