[llvm-dev] RFC: New function attribute HasInaccessibleState

Fri Dec 4 11:59:21 PST 2015

>-----Original Message-----
>From: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] On Behalf Of Hal
>Finkel via llvm-dev
>Sent: Friday, December 04, 2015 10:34 AM
>To: Vaivaswatha Nagaraj <vn at compilertree.com>
>Cc: LLVM Dev <llvm-dev at lists.llvm.org>
>Subject: Re: [llvm-dev] RFC: New function attribute HasInaccessibleState
>
>----- Original Message -----
>> From: "Vaivaswatha Nagaraj" <vn at compilertree.com>
>> To: "James Molloy" <james at jamesmolloy.co.uk>, "Hal Finkel"
><hfinkel at anl.gov>
>> Cc: "LLVM Dev" <llvm-dev at lists.llvm.org>
>> Sent: Friday, December 4, 2015 12:28:03 PM
>> Subject: Re: [llvm-dev] RFC: New function attribute HasInaccessibleState
>>
>> 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)
>>
>
>More generally, I think this attribute is supposed to mean, "this function might
>access globals, but none of these globals are things you can name in the IR
>being optimized." You might, of course, pass in aliasing memory as a
>parameter, but that's a separate matter.

This seems really close.  In reading through the whole chain, it seems like this is trying to define a sort of amorphous environmental state, which
cannot be represented in the IR, but which a function with the "HasInaccessibleState" attribute somehow may read and modify. I'd go so far as
to say that this environmental state is more than just some unaliasable global variables.

Now, with that said, it sort of seems similar to volatile for memory references.  " The optimizers must not change the number of volatile operations or change their order of execution relative to other volatile operations. The optimizers may change the order of volatile operations relative to non-volatile operations."

So, maybe a "volatile" function attribute.  And this means simply that calls to such a function may not change their order (or number) of execution relative to other volatile operations. I think this
covers the desired functionality expressed here, and is consistent with David Majnemer's suggestion of non-cseable as well.  This also takes into account functions that do IO, or that affect the external environment, like passing a message to another process.

Kevin Smith

>
> -Hal
>
>>
>> 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.
>
>--
>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