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

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>

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>

----- Original Message -----
> From: "James Molloy via llvm-dev" <llvm-dev at
lists.llvm.org>
> To: "Vaivaswatha Nagaraj" <vn at compilertree.com>
> Cc: "LLVM Dev" <llvm-dev at lists.llvm.org>
> Sent: Thursday, December 3, 2015 4:41:46 AM
> Subject: Re: [llvm-dev] Function attributes for LibFunc and its impact on
GlobalsAA
> 
> 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?
This is unlikely to be desirable. A readnone function is one whose output is a
function only of its inputs, and if you have this:

  int *x = malloc(4);
  *x = 2;
  int *y = malloc(4);
  *y = 4;

you certainly don't want EarlyCSE to replace the second call to malloc with
the result of the first (which it will happily do if you mark malloc as
readnone).

readonly is a more-interesting question, because, in practice, this will
currently work. It works, however, for the wrong reason (as I recall, we
currently don't CSE readonly calls because we need to assume that they might
have infinite loops, which is a problem we need to otherwise fix). Thus, marking
it readonly is probably not a good long-term plan.

Given that malloc is an important special case, however, giving it special
handling is potentially reasonable (we have isMallocLikeFn and
isOperatorNewLikeFn in MemoryBuiltins.h). One might argue that tagging malloc()
as readonly might break an LTO build, but doing so already potentially has
problems because of our aliasing assumptions. malloc hooks are an interesting
point, but those are not standard, not commonly used, can already cause
violations of our aliasing assumptions, and the problem that hooking libc
functions that we assume are readonly in a way that changes state visible to the
caller might break things is not unique to malloc. Users always have the option
of turning off these kinds of assumptions by compiling with -fno-builtin-malloc.

 -Hal
> 
> 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
> 
> 
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
> 
-- 
Hal Finkel
Assistant Computational Scientist
Leadership Computing Facility
Argonne National Laboratory