[llvm-dev] RFC: New function attribute HasInaccessibleState
Vaivaswatha Nagaraj via llvm-dev
llvm-dev at lists.llvm.org
Fri Dec 4 10:15:59 PST 2015
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:
>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
>the format string for %n).
>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
>> I now understand the concern. It looks to me that we will need to set
>> flag by default to all functions whose definitions aren't available
>> (external), and then propagate from there on. I don't see any
>> 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.
>> we address this problem?
>> Yes, this is the primary concern. Most libc functions (including
>> 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
>>> > >> 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
>>> libc. This is actually quite tricky to support, semantically, and
>>> breaks our malloc aliasing assumptions. There are many legitimate
>>> LLVM, both for statically-compiled code and for JIT'd code, that
>>> a visibility boundary between certain core runtime services and the
>>> 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
>>> to adjust our malloc noalias assumptions, if not many other things).
>>> 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.
>>> we address this problem?
>>> Thanks again,
>>> > _______________________________________________
>>> > 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
Sent from my Android device with K-9 Mail. Please excuse my brevity.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the llvm-dev