It is possible that dependent instruction may access memory.
In this case we must reject optimization because the memory change will
be visible in null handler basic block. So we will execute an instruction which
we must not execute if check fails.
Details
Diff Detail
- Repository
- rL LLVM
Event Timeline
lgtm with minor comments
lib/CodeGen/ImplicitNullChecks.cpp | ||
---|---|---|
315 ↗ | (On Diff #109966) | IIUC this isn't optimal -- we can early return with AR_MayAlias when processing further would have given us AR_WillAliasEverything. |
322 ↗ | (On Diff #109966) | Minor, but I'd be consistent here and either take both as refs or pointers. |
343 ↗ | (On Diff #109966) | There are too many continues and returns here -- do you mind splitting out a mayAlias(MachineMemOperand *, MachineMemOperand *) helper? |
369 ↗ | (On Diff #109966) | s/has value/have values/ |
470 ↗ | (On Diff #109966) | I vaguely remember that originally we did not allow the dependence MI to touch memory. Do you know when this changed (or am I misremembering)? |
Hi Sanjoy, thank you for the quick review and a good point about stores at all. I think this patch is incorrect and will upload other version soon.
lib/CodeGen/ImplicitNullChecks.cpp | ||
---|---|---|
470 ↗ | (On Diff #109966) | This is really good question and I came to it last night (before going to sleep) as well. Please note that we have already prohibit loads (line 428 this file). And we should do the same for store. Actually I've discussed this today with Philip offline and he made a good point about DependenceMI. It should not do any visible side-effects to the branch handling null case. We already check the definition of registers. Also we do not allow different instructions like call. We should not allow stores (will upload a patch). I will also check whether we cover other cases if they exists. |
Thank you Sanjoy!
You asked about when we allowed stores. DependenceMI did not check for stores but it was hidden in canHandle. when I implemented INC based on stores and added alias analysis I removed the check from canHandle but did not add it to DependenceMI. so it was my fault.