[PATCH] D101440: [DSE] Eliminate store after calloc (PR50143)

Dávid Bolvanský via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Thu Apr 29 14:32:20 PDT 2021


xbolva00 added inline comments.


================
Comment at: llvm/lib/Analysis/AliasAnalysis.cpp:241
   if (onlyAccessesInaccessibleMem(MRB))
-    return ModRefInfo::NoModRef;
+    return isAllocLikeFn(Call, &TLI) ? ModRefInfo::Mod : ModRefInfo::NoModRef;
 
----------------
xbolva00 wrote:
> xbolva00 wrote:
> > nikic wrote:
> > > xbolva00 wrote:
> > > > fhahn wrote:
> > > > > From this workaround, it seems like how `inaccessiblememonly` is used for `calloc` does not completely match AA's interpretation. Are there other cases in the code base? I'm not sure if special casing `calloc` here is ideal. 
> > > > > 
> > > > > I think we should probably treat the `AA` change as a separate patch, with an AA only test as well, perhaps `llvm/test/Analysis/BasicAA/libfuncs.ll`?
> > > > Not only calloc, all alloc (calloc, malloc, aligned_alloc) fns have inaccessiblememonly. inaccessiblememonly was introduced long time ago but this attribute was basically dead, no libfunc used it until recently.
> > > > 
> > > > 
> > > > Sadly, inaccessiblememonly is somehow broken nowdays as the code assumes that such call does not write or read memory, but of course it returns memory.
> > > > 
> > > > This AA change can be separated patch (but this DSE needs it as a prerequisite)
> > > > 
> > > > 
> > > > Another solution is removal of inaccessiblememonly from alloc fns, as it caused more harm then improvements.
> > > Your new implementation claims that inaccessiblememonly alloc-like fns mod all locations -- if that's what you want, just drop the attribute from the functions entirely. That will have about the same effect.
> > > 
> > > I think inaccessiblememonly is fine for modeling malloc behavior (or do you see any issues there as well?), the problem is with calloc which combines malloc (inaccessiblememonly) with a write to the location (accessible). As @jdoerfert already pointed out on the PR, properly modelling this would require "inaccessible_or_returned_memonly".
> > > 
> > > While I'm somewhat open to DSE hacks, I don't think making this change on the AA layer is acceptable. I think dropping inaccessiblememonly inference for calloc() specifically would be the right thing to do in the meantime.
> > Yeah, I will just drop it from calloc.
> >> I think inaccessiblememonly is fine for modeling malloc behavior (or do you see any issues there as well?)
> 
> Just found one I think.
> 
> Imagine you want to change malloc+memset combo to calloc 
> 
>          auto *UnderlyingDef =
>               cast<MemoryDef>(MSSA.getMemoryAccess(MallocInst));
>           // If UnderlyingDef is the clobbering access of Def, no instructions
>           // between them can modify the memory location.
>           auto *ClobberDef =
>               MSSA.getSkipSelfWalker()->getClobberingMemoryAccess(MemsetDef);
>           return UnderlyingDef == ClobberDef;
>         
> This will fail.
I am wondering whether there is other solution or should I just remove inaccessiblememonly from malloc too?

@jdoerfert @fhahn 

I tried also to use memoryIsNotModifiedBetween but 
MemoryLocation MemLoc = MemoryLocation::get(MemsetInst)

MemLoc is None


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

https://reviews.llvm.org/D101440



More information about the llvm-commits mailing list