[llvm-dev] RFC: New function attribute HasInaccessibleState

[Vaivaswatha Nagaraj via llvm-dev]

writing into operands is not the same as writing to globals right? I added printf in the same category since we were discussing writing to globals. 

On December 4, 2015 11:34:10 PM GMT+05:30, James Molloy <james at jamesmolloy.co.uk> wrote:
>Hi,
>
>I just want to reiterate: printf and friends do *not* fall into this
>category as they can write to their operands (unless you parse and
>check
>the format string for %n).
>
>James
>
>On Fri, 4 Dec 2015 at 17:53 Vaivaswatha Nagaraj via llvm-dev <
>llvm-dev at lists.llvm.org> wrote:
>
>> >Most of the time you don't have the entire call graph information.
>> Imagine that you are developing a module that is a part of a larger
>project.
>> I now understand the concern. It looks to me that we will need to set
>the
>> flag by default to all functions whose definitions aren't available
>> (external), and then propagate from there on. I don't see any
>optimizations
>> being inhibited by such a setting, so it should be okay.
>>
>>
>> >I think we need to go back and look at the underlying use case (as I
>> understand it): GlobalAA should be able to figure out that calls to
>> malloc/free don't touch global variables visible to the optimizer.
>How do
>> we address this problem?
>> Yes, this is the primary concern. Most libc functions (including
>printf,
>> malloc, free) fall into the same category.
>>
>>
>>   - Vaivaswatha
>>
>> On Fri, Dec 4, 2015 at 11:12 PM, Hal Finkel <hfinkel at anl.gov> wrote:
>>
>>> ----- Original Message -----
>>> > From: "Vaivaswatha Nagaraj via llvm-dev" <llvm-dev at lists.llvm.org>
>>> > To: "Krzysztof Parzyszek" <kparzysz at codeaurora.org>
>>> > Cc: "LLVM Dev" <llvm-dev at lists.llvm.org>
>>> > Sent: Friday, December 4, 2015 11:21:03 AM
>>> > Subject: Re: [llvm-dev] RFC: New function attribute
>>> > HasInaccessibleState
>>>
>>> > >> In the case of user-defined allocation functions, the
>definitions
>>> > >> for those functions are available
>>>
>>> > >Are they? probably not unless you're in an LTO build.
>>>
>>> > Yes, I'm assuming an LTO build.
>>>
>>> The concerns around LTO here, while legitimate, apply only to a
>>> very-specific kind of LTO: An LTO which includes the definitions of
>the
>>> libc. This is actually quite tricky to support, semantically, and
>already
>>> breaks our malloc aliasing assumptions. There are many legitimate
>uses of
>>> LLVM, both for statically-compiled code and for JIT'd code, that
>depend on
>>> a visibility boundary between certain core runtime services and the
>user
>>> code being compiled to provide for effective optimization.
>>>
>>> So, yes, this will break LTO when you include libc itself in the
>>> optimization process. We already don't support this (we'd need, at
>least,
>>> to adjust our malloc noalias assumptions, if not many other things).
>I
>>> don't think this is a major concern.
>>>
>>> I think we need to go back and look at the underlying use case (as I
>>> understand it): GlobalAA should be able to figure out that calls to
>>> malloc/free don't touch global variables visible to the optimizer.
>How do
>>> we address this problem?
>>>
>>> Thanks again,
>>> Hal
>>>
>>> ...
>>>
>>> > _______________________________________________
>>> > 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
>>>
>>
>> _______________________________________________
>> LLVM Developers mailing list
>> llvm-dev at lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20151204/764555a0/attachment.html>