llvm dev - Dec 2015 - Function attributes for LibFunc and its impact on GlobalsAA

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20151202/058320db/attachment.html>

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/e98a361f/attachment.html>

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>