[PATCH] D64101: [LoopUnroll] fix cloning callbr

Nick Desaulniers via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Wed Jul 3 10:48:00 PDT 2019


nickdesaulniers added inline comments.


================
Comment at: llvm/lib/Transforms/Utils/LoopUnroll.cpp:91
+      if (It != VMap.end() && isa<CallBrInst>(*I))
+        if (auto *NewBB = dyn_cast<BasicBlock>(It->second))
+          I->setOperand(OpNo, BlockAddress::get(NewBB));
----------------
fhahn wrote:
> Is it possible for It->second to not be a BB here? I think if the original operand was a BB, the new one also should be a BB. So this could be a regular cast?
> Is it possible for It->second to not be a BB here?

I'm pretty sure `It->second` can ONLY be a `BasicBlock` here, since the values stored in `VMap` were created by `llvm::CloneBasicBlock` (see `VMap` there).

That said, I'm not super confident in my understanding of `dyn_cast` vs `static_cast`.

The `VMap` is an instance of `ValueToValueMapTy`, which simply maps `Value*` to `Value*`.  As `Value` is the base class of a lot of stuff in LLVM, we end up storing all kinds of pointers to derived classes in `VMap`.

My understanding of when to use `dyn_cast` (or even `dynamic_cast`) vs `static_cast` is that it's always ok to `static_cast` from derived class to base class, but not vice versa.  That's why `dyn_cast` or `dynamic_cast` might result in `nullptr` at runtime, and thus need to be checked.

Since `It->second` should ALWAYS (IIUC) be a `BasicBlock*` in this case, I would have thought we still need a checked call to `dyn_cast`.

Maybe I'm misunderstanding and that it's ok to `static_cast` from base to derived if you're certain that base is always derived?


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D64101/new/

https://reviews.llvm.org/D64101





More information about the llvm-commits mailing list