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

[Johannes Doerfert via llvm-dev]

What Michael said. You can also use

   -fno-builtin-<value>    Disable implicit builtin knowledge of a 
specific function

   -fno-builtin            Disable implicit builtin knowledge of functions


On 4/30/20 12:36 PM, Michael Kruse wrote:
> 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