[llvm-dev] RFC: New function attribute HasInaccessibleState

[James Molloy via llvm-dev]

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>