[llvm-dev] RFC: New function attribute HasInaccessibleState

[James Molloy via llvm-dev]

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