[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