[loop-deletion] Improve analysis on calls when deleting a loop.
Diff Detail
- Build Status
Buildable 4201 Build 4201: arc lint + arc unit
Event Timeline
test/Transforms/LoopDeletion/no-sideeffect-call.ll | ||
---|---|---|
26 | 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.) |
test/Transforms/LoopDeletion/no-sideeffect-call.ll | ||
---|---|---|
26 | 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. 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). |
test/Transforms/LoopDeletion/no-sideeffect-call.ll | ||
---|---|---|
26 | 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. |
Well, you could in theory delete a loop which contains an argmemonly call if you can prove the modified memory isn't used outside the loop... but that doesn't come up in practice, as far as I know. Beyond that, I don't think you can do anything interesting with alias analysis.
Yes, as you are deleting the loop as a whole. I think its OK to remove that comment then at this point, right ?
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.)