llvm dev - Dec 2015 - RFC: New function attribute HasInaccessibleState

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

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

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/764555a0/attachment.html>