[PATCH] D48396: [MemorySSA] Add APIs to MemoryPhis to delete incoming blocks/values, and an updater API to remove blocks.
Alina Sbirlea via Phabricator via llvm-commits
llvm-commits at lists.llvm.org
Tue Jun 26 14:16:05 PDT 2018
asbirlea added inline comments.
================
Comment at: lib/Analysis/MemorySSA.cpp:1576
BlockNumbering.erase(MA);
+ BlockNumberingValid.erase(MA->getBlock());
if (auto *MUD = dyn_cast<MemoryUseOrDef>(MA))
----------------
george.burgess.iv wrote:
> The numbering is still valid even if we remove MA, though :)
>
> We don't really care if the numbering has gaps. We only care that the block numbers increase as you iterate through an AccessList.
You're right :). Moved to `removeFromLists`.
================
Comment at: lib/Analysis/MemorySSAUpdater.cpp:501
+ TerminatorInst *TI = BB->getTerminator();
+ if (TI)
+ for (BasicBlock *Succ : TI->successors()) {
----------------
george.burgess.iv wrote:
> asbirlea wrote:
> > george.burgess.iv wrote:
> > > nit: `if (TerminatorInst *TI = BB->getTerminator())`.
> > >
> > > Do we expect to see broken IR here, though? It's my impression that BBs should always have a terminator when they're in a complete-enough state.
> > >
> > > If yes, please add a comment explaining how broken we expect our IR to be when this method is called. :)
> > TI should be null for empty blocks. I don't have a use case, but it seemed a reasonable safety check. I can remove it if you think it's unnecessary.
> > I extended the header comment with the amount of "broken-ness" to be expected :).
> Personally, I have a slight preference for asserting that the IR is well-formed until we know that we can't, but if you'd prefer to have a check here, I'm OK with that.
Ack, adding an assert. If I find a usecase later, I'll change it to a check.
Repository:
rL LLVM
https://reviews.llvm.org/D48396
More information about the llvm-commits
mailing list