[llvm-dev] Function attributes for memory side-effects

[Alexey Zhikhartsev via llvm-dev]

Hi Johannes,

This got me puzzled:

> In case of library functions we actually "know" the side effects and will
add the appropriate attributes.

How can we make sure that a function in the LLVM IR is a specific library
function and not something that the user wrote themself? For example, we
see a call to "printf" in the code but it could be a function that just
happened to be named "printf" that does all sorts of things that we
wouldn't expect from a genuine libc printf.

Alexey

On Thu, Apr 30, 2020 at 11:35 AM Johannes Doerfert via llvm-dev <
llvm-dev at lists.llvm.org> wrote:

>
> On 4/29/20 4:12 PM, Reid Kleckner via llvm-dev wrote:
>  > On Tue, Apr 28, 2020 at 12:58 PM Ejjeh, Adel via llvm-dev <
>  > llvm-dev at lists.llvm.org> wrote:
>  >
>  >> Specifically, I want to be able to know when a called function does not
>  >> have any side effects (e.g. math library functions like sqrt)
>  >>
>  >
>  > Apologies for the pedantry, but I believe sqrt may set errno, so it
>  > actually can have side effects. :( See -fno-math-errno and the
>  > documentation around it.
>  >
>  >
>  >> , and was wondering if there are attributes that specify this
> behavior (I
>  >> know there is the ‘noread’ attribute but wasn’t sure if there’s
> something
>  >> similar for writes)? Also, how can I tell clang to generate those
>  >> attributes at the function declaration? Any information would be
> helpful.
>  >>
>  >
>  > Yep, I believe the IR attributes are `readonly` and `readnone`. Readonly
>  > implies no side effects (no writes), and readnone implies no memory
>  > dependencies at all. The return value is a pure function of the
> arguments.
>  > Two calls with the same arguments can be folded together.
>  >
>  > There are a couple of passes (Attributor, FunctionAttrs, I'm not
>  > up-to-date) that will infer these attributes if they can see a precise
>  > definition of the function body. Learning anything interesting usually
>  > requires expanding the scope of analysis with LTO, so these passes
> can look
>  > across translation unit boundaries.
>
> Often true. In case of library functions we actually "know" the side
> effects and will add the appropriate attributes. As you said, fast math
> flags are needed for math library functions that may otherwise write
> errno.
>
>
> The full list of attributes we have so far is:
>
>     access locations: `readnone`, `inaccessiblememonly`, `argmemonly`,
> and `inaccessiblemem_or_argmemonly`
>   and access "kinds": `readonly` and `writeonly`
>
> Except for `readnone` you can combine a location attribute with a "kind"
> or have one of either alone. The Attributor does internally derive more
> "locations", basically any combination of:
>    local memory
>    constant memory
>    internal global memory
>    external global memory
>    argument memory
>    inaccessible memory
>    malloced memory (returned by a function with the `noalias` return
> attribute)
>    unknown memory
> I want to add some/all of these as attributes but didn't find the time
> yet.
>
>
> Cheers,
>
>    Johannes
>
>
>
>  >
>  > HTH
>  >
>  >
>  > _______________________________________________
>  > LLVM Developers mailing list
>  > llvm-dev at lists.llvm.org
>  > https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://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/20200430/5f573672/attachment.html>