[llvm-dev] Function attributes for LibFunc and its impact on GlobalsAA
James Molloy via llvm-dev
llvm-dev at lists.llvm.org
Thu Dec 3 02:41:46 PST 2015
Hi,
I think that might be difficult to detect. If you wanted to force this
behaviour in your own toolchain, you could just use "-mllvm
-force-attribute=malloc:readnone" on the clang command line?
James
On Thu, 3 Dec 2015 at 10:21 Vaivaswatha Nagaraj <vn at compilertree.com> wrote:
> 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/0214f4a0/attachment-0001.html>
More information about the llvm-dev
mailing list