[llvm-dev] RFC: New function attribute HasInaccessibleState

[Vaivaswatha Nagaraj via llvm-dev]

that would be an escaping global, and as far as I know is handled separately in GlobalsAA (AnalyzeUsesOfPointer checks if a global is used as operand to a function) 

On December 4, 2015 11:47:20 PM GMT+05:30, James Molloy <james at jamesmolloy.co.uk> wrote:
>It is if one of the operands is or can alias a global ?
>On Fri, 4 Dec 2015 at 18:16, Vaivaswatha Nagaraj <vn at compilertree.com>
>wrote:
>
>> 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.
>>

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