[llvm-dev] RFC: New function attribute HasInaccessibleState

[Vaivaswatha Nagaraj via llvm-dev]

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

>Printf() is a very nasty one because it can actually affect a lot of
state. The %n modifier can cause an argument to be written to.
hence it would have HasInaccessibleState and ArgMemOnly set, but not
ReadNone or ReadOnly set.

>Yes. Definitions being available should only *increase* the set of
attributes that can be added to them, never decrease.
I agree with that. But what I meant was, during a compilation invocation,
we either have the definitions available or not. That means, the attributes
we set once (or not set if definition isn't available) does not change.

>That's in practice impossible to guarantee, both by the compiler and by
the programmer.
I'm not sure I understand this. Why would it be impossible for the compiler
to propagate this flag along the call graph upwards? As an example, malloc
has the flag set, and this is propagated to whoever calls malloc, and then
to whoever calls that function and so on.



  - Vaivaswatha

On Fri, Dec 4, 2015 at 10:24 PM, Krzysztof Parzyszek via llvm-dev <
llvm-dev at lists.llvm.org> wrote:

> On 12/4/2015 10:48 AM, Vaivaswatha Nagaraj via llvm-dev wrote:
>
>> This point however reminds me to add, functions that transitively call
>> functions with HasInaccessibleState must also have the flag set.
>>
>
> That's in practice impossible to guarantee, both by the compiler and by
> the programmer.
>
> -Krzysztof
>
> --
> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted
> by The Linux Foundation
>
> _______________________________________________
> 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/f045ff1c/attachment.html>