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

[Michael Kruse via llvm-dev]

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