[llvm-dev] RFC: New function attribute HasInaccessibleState

Fri Dec 4 16:32:52 PST 2015

----- Original Message -----
> From: "Mehdi Amini" <mehdi.amini at apple.com>
> To: "Hal Finkel" <hfinkel at anl.gov>
> Cc: "Vaivaswatha Nagaraj" <vn at compilertree.com>, "LLVM Dev" <llvm-dev at lists.llvm.org>
> Sent: Friday, December 4, 2015 12:47:00 PM
> Subject: Re: [llvm-dev] RFC: New function attribute HasInaccessibleState
> 
> 
> > On Dec 4, 2015, at 10:33 AM, Hal Finkel via llvm-dev
> > <llvm-dev at lists.llvm.org> wrote:
> > 
> > ----- 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.
> 
> I’m not what "things you can name in the IR” mean exactly, would this
> be equivalent to "none of these globals can alias with any memory
> location accessible from the IR being optimized”?
> 
> To come back to what I phrased earlier, this effectively split the
> state in two distinct parts, is this enough in all cases? Would
> there be some need/benefit to model more partitions?

I agree this is a good question. I don't have any use cases right now where modeling multiple external states would be useful.

There might be a relationship to our long-standing problem of modeling errno, but that does not quite fit into this model, because errno is sometimes implemented as a global.

 -Hal

> 
> Thanks,
> 
> —
> Mehdi
> 
> > 
> >> 
> >> 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
> 
> 

-- 
Hal Finkel
Assistant Computational Scientist
Leadership Computing Facility
Argonne National Laboratory