[PATCH] D30284: [loop-deletion] Improve analysis on calls when deleting a loop.

Xin Tong via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Wed Feb 22 19:39:40 PST 2017


trentxintong added inline comments.


================
Comment at: test/Transforms/LoopDeletion/no-sideeffect-call.ll:26
+if.then:
+  %call = call float @sqrtf(float %x) #0
+  br label %if.end
----------------
trentxintong wrote:
> efriedma wrote:
> > mayHaveSideEffects isn't returning the expected result on your testcase because this call isn't marked nounwind.  (I suspect your patch isn't actually doing anything useful.)
> I debugged this a bit, basically we return FMRB_DoesNotAccessMemory if the callsite has the ReadNone attribute and that makes AliasAnalysis::onlyReadsMemory(Bev) true.
> 
> 581  /// Returns the behavior when calling the given call site.
> 582  FunctionModRefBehavior BasicAAResult::getModRefBehavior(ImmutableCallSite CS) {
> -> 583    if (CS.doesNotAccessMemory())
> 584      // Can't do better than this.
> 585      return FMRB_DoesNotAccessMemory;
> 
> I used to think readnone/readonly cant not unwind implicitly. But it seems it has been changed. Maybe the check here needs to be ReadNone/ReadOnly + Nounwind. With this that means the call can not write to LLVM visible memory nor LLVM invisible memory (Nounwind).
I think you are right. I think calling mayHaveSideEffects on the CallInst will check for callsite specific attributes as well as attributes on the function.  I wonder what the comment "This could be made more aggressive by using aliasing information to identify readonly and readnone calls." is there then. Maybe its out-of-dated or there is something I am missing here.


https://reviews.llvm.org/D30284





More information about the llvm-commits mailing list