[llvm-dev] Function attributes for LibFunc and its impact on GlobalsAA

[Vaivaswatha Nagaraj via llvm-dev]

Hi James,

Thank you for the response. I understand the concern about malloc/free
hooks. Could we detect that a program has setup malloc hooks (assuming
we're in a whole program compilation) and make assumptions (such as
onlyAccessesArgMem()) when the program hasn't setup malloc hooks? Using a
command line flag could be one option too.

I'm currently working on a program where having these attributes could help
GlobalsAA give significantly more precise results. Considering that this
info is propagated to the caller, its caller and so on, this may have a
wider impact than the program I'm currently looking at.

Thanks,

  - Vaivaswatha

On Thu, Dec 3, 2015 at 2:57 PM, James Molloy <james at jamesmolloy.co.uk>
wrote:

> Hi Vaivaswatha,
>
> I think not adding readnone/readonly to malloc/realloc is correct.
> malloc/free hooks can be added to most implementations (for leak checking
> and so on), so calling malloc could in fact call any other arbitrary code
> that could write to memory.
>
> Cheers,
>
> James
>
> On Wed, 2 Dec 2015 at 14:07 Vaivaswatha Nagaraj via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
>
>> Hi,
>>
>> GlobalsAA, during propagation of mod-ref behavior in the call graph,
>> looks at library functions (in GlobalsAAResult::AnalyzeCallGraph:
>> F->isDeclaration() check), for attributes, and if the function does not
>> have the onlyReadsMemory attribute set, forgets it.
>>
>> I noticed that library functions such as malloc/realloc do not have the
>> attributes doesNotAccessMemory or onlyReadsMemory respectively set
>> (FunctionAttrs.cpp). This leads to a loss of GlobalsAA information in the
>> caller (and its caller and so on). Aren't these attributes stricter than
>> necessary currently? I do not see why the presence of malloc/realloc in a
>> function needs to invalidate all mod-ref info gathered for that function so
>> far.
>>
>> Please let me know if the question is not clear. I'll try to extract out
>> a simple test case from the program I'm looking at and post it, so as to
>> have a concrete example.
>>
>> Thanks,
>>
>>   - Vaivaswatha
>> _______________________________________________
>> LLVM Developers mailing list
>> llvm-dev at lists.llvm.org
>> http://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/20151203/67eea405/attachment.html>