llvm dev - Apr 2020 - Function attributes for memory side-effects

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

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>

Frontends are supposed to add a "nobuiltin" attribute to functions
that do not correspond to the semantics of the C library function with
the same name.

Michael

Am Do., 30. Apr. 2020 um 10:46 Uhr schrieb Alexey Zhikhartsev via
llvm-dev <llvm-dev at lists.llvm.org>:
>
> 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
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev

Johannes, Reid

Thanks for this input. I somehow missed this entire chain earlier and only just
saw your replies! I tried with the fast-math flag and it indeed did produce the
readnone attribute for the sqrt function (the attribute was not generated
without fast-math).

Regards
-Adel

On 4/30/20, 10:36 AM, "Johannes Doerfert" <johannesdoerfert at
gmail.com> 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