[PATCH] Intercept allocation to skim allocated types

[Douglas Gregor]

Hello Dai,

Eric Christopher has a ton of knowledge about this area of the compiler. I think he'll be able to help more than I.

	- Doug

On Mar 18, 2013, at 2:30 AM, Dai MIKURUBE <dmikurube at acm.org> wrote:

> Hi John and Douglas,
> 
> Sorry for my mails a lot of times, but I found that just the first
> part of your suggestion would work enough for our purpose!
> 
> It works for our purpose only with the association of 1) the type of a
> particular "new" expression and 2) the address at which the call to
> operator new occurs (DWARF does this sort of thing) as you suggested.
> It's because we already have a malloc profiler, and we focus on
> malloc'ed memory blocks.  A result of the malloc profiler should have
> the address at which the call to operator new occurs.
> 
> 
> Could you introduce the expected reviewer for that?  I think I'll be
> starting to implement your suggestion soon, but I'd like to discuss
> the rough design and how to implement it before starting.
> 
> # I wonder if I could attend the next LLVM devmtg, and talk about it
> with him or her face-to-face quickly.
> 
> 2013/2/27 Dai MIKURUBE <dmikurube at acm.org>:
>> Hi John,
>> 
>> Thank you for your reply.
>> 
>> 
>> 2013/2/27 John McCall <rjmccall at apple.com>
>>> 
>>> On Feb 24, 2013, at 12:38 AM, Dai MIKURUBE <dmikurube at acm.org> wrote:
>>>> Hi Douglas and John,
>>>> 
>>>> I started to try your approach, but I'm still not sure what it does, and
>>>> still a little doubtful that it's easy to catch allocation by non-global
>>>> (in-class) operator news.  When a project has 100 in-class operator news,
>>>> doesn't it need to prepare 101 replacement functions?  If it needs, I think
>>>> it's so unrealistic.  We cannot track all changes in a big project (e.g.
>>>> WebKit).  If a developer adds a new class with its local operator new, it's
>>>> impossible to track all such local operator news.
>>>> 
>>>> Could you tell me make sure 1) what should happen in the compiler and 2)
>>>> what replacement functions should be added, in the simple example below?
>>>> 
>>>> (Also, I'd like to know where is the DWARF code in Clang you mentioned.)
>>> 
>>> Okay, here's the deal.
>>> 
>>> I don't think we're really interested in taking your original language
>>> extension into mainline clang.  It's invasive, it's complicated, it's novel,
>>> and it doesn't seem to have broad applicability.
>>> 
>> Yes and yes, your point on my original extension is right at all.  I also
>> think it's complicated.  (So, I asked about it at cfe-dev@ weeks ago, before
>> I started implementing for upstream since I was worried about its
>> complicacy.)
>> 
>> I don't want to stick on my original proposal, and I don't want to
>> contradict your suggestion.  I *just* wanted hints to understand Douglas's
>> suggestion (maybe just simple answers to my questions) since I didn't
>> well-understand how his suggestion should be implemented and how the
>> implementation should work.  If it's not enough for our purpose, I'll think
>> out another idea.  Or, any other suggestions are also welcome.
>> 
>> What do you think, Douglas?
>> 
>> 
>>> 
>>> Doug and I were suggesting adding infrastructure to LLVM under which
>>> arbitrary calls could be annotated with metadata which would potentially
>>> survive into DWARF.  This would be a broadly-applicable feature that could
>>> be used by potentially many projects.  This would be a lot of work on your
>>> part, but as a carrot, we would be open to an extension which merely
>>> annotates an operator new call using this new LLVM feature.  It may not,
>>> however, actually achieve your purposes that well;  I don't know them well
>>> enough to speculate.
>>> 
>>> Ultimately, however, this is an open-source project, and you are welcome
>>> to maintain your patch out-of-tree.
>>> 
>>> John.
>> 
>> 
>> 
>> 
>> --
>> Dai MIKURUBE
>>   dmikurube at acm.org
> 
> 
> 
> --
> Dai MIKURUBE
>   dmikurube at acm.org

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20130325/7b8f1926/attachment.html>