[PATCH] D65402: [Attributor][MustExec] Deduce dereferenceable and nonnull attribute using MustBeExecutedContextExplorer

Johannes Doerfert via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Thu Aug 15 06:48:49 PDT 2019


jdoerfert added a comment.

In D65402#1631204 <https://reviews.llvm.org/D65402#1631204>, @xbolva00 wrote:

> Hello folks,
>
> Yesterday I came up with idea to annonate allocation functions with deref_or_null.
>
> malloc(40) -> annotate return value of malloc with deref_or_null(40) -> Good, I will work on this idea.
>
> Now I present some ideas for Attributor (maybe following cases already work.. I didnt check them).
>
> Use case 1:
>  p = malloc(40) //  deref_or_null(40)
>  p[1] = 100; // here, we can change  deref_or_null(40) to  deref(40) since if p was null, it is UB.


This should work with these patches, yes. (It will be deref(40) if nullptr is not a valid pointer else it is deref(2).)

> Use case 2:
>  p = malloc(40) //  deref_or_null(40)
>  if (p) {
> 
>   in this block p is now  deref(40)! cool.
> 
> }

Yes, this will work at some point soon, it might already if the nonnull query is already using the "context instruction". However, there might not be a way to annotate the information. Passes will soon (after the series that ends in D66276 <https://reviews.llvm.org/D66276>) be able to build a Attributor and query a single property, e.g., the dereferenceability property of a pointer inside some control. We might also think about better dereferenceability annotations, maybe an intrinsic. This also ties in with the new deref and deref_globally (D61652 <https://reviews.llvm.org/D61652>).

> Use case 3
>  p = malloc(40) //  deref_or_null(40)
>  if (someotherbool) {
> 
>   p[1] = 100; // here, we can change  deref_or_null(40) to  deref(40) since if p was null, it is UB.
> 
> }

Similar to above.

> What do you think? Can attributor do it? I think use case 1 is doable, 2 and 3 a bit harder ones.

All are well in the scope of what we (will soon) have.

> Maybe @reames is interested too in this area? Please comment this idea :)
> 
> I think precise deref info can enable really neat things, see https://bugs.llvm.org/show_bug.cgi?id=43003.

Once these patches are in we need to switch to deref and deref_globally (D61652 <https://reviews.llvm.org/D61652>). We should also consider using deref_globally (or sth similar) to indicate that all existing accesses will be dereferenceable, e.g.,
if we have an alloc or a malloc for which we can show it returns sth dereferenceable and the pointer is not used after the free.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D65402/new/

https://reviews.llvm.org/D65402





More information about the llvm-commits mailing list