Details
Diff Detail
- Repository
- rL LLVM
Event Timeline
include/polly/Support/ScopHelper.h | ||
---|---|---|
81 ↗ | (On Diff #47939) | The distinction between implicit an explicit constructors is lost with this. In particular, I'd avoid an arbitrary Instruction to be converted to MemAccInst without a kind of explicit 'cast'. This makes a execution-time error out of it, including if passing someting that is not even an Instruction. |
86 ↗ | (On Diff #47939) | classof is intended for LLVM's object hierarchy and MemAccInst is no part of it. It is not derived from llvm::Value or similar. That means eg. LoadInst *LI; cast<MemAccInst>(LI) will go horribly wrong. |
97 ↗ | (On Diff #47939) | This scheme doesn't work in general when we want something implicitly converted to the argument. Though, in this case, because nothing derives from LoadInst or StoreInst, there might be no such case. I'd still prefer the previous for readability. |
102 ↗ | (On Diff #47939) | No StaticAssertLegalT here? |
106 ↗ | (On Diff #47939) | That's want I suggested an planned as well. |
115 ↗ | (On Diff #47939) | Is there any advantage of this scheme that two ifs? Both have 5 lines. |
126 ↗ | (On Diff #47939) | I'd rather avoid using macros, but still OK. |
147 ↗ | (On Diff #47939) | Wow, I didn't know this is possible. |
Will refine the patch
include/polly/Support/ScopHelper.h | ||
---|---|---|
81 ↗ | (On Diff #47939) | ok |
86 ↗ | (On Diff #47939) | It works if we introduce simplify_type, and I actually experimented this and confirm it work. I think it should be return I && (llvm::isa<llvm::LoadInst>(I) || llvm::isa<llvm::StoreInst>(I)); |
97 ↗ | (On Diff #47939) | ok |
102 ↗ | (On Diff #47939) | We call "operator=(T *)" which has the StaticAssertLegalT |
115 ↗ | (On Diff #47939) | I dont think it has advantage, this together with the following macro are copied from CallSite... I first copy here then copy to the following marco |
126 ↗ | (On Diff #47939) | We may think about using template to do the same thing when we have time. |
Still working in it? Due to MemIntrinsics, the macroization/templatization doesn't work anymore?.?
Originally, I actually waiting @jdoerfert to checkin his patches and work on it. Now I can continue
not blocking, I just think this one is not as high priority as yours, so I
just wait to avoid unnecessary rebase on your side
LGTM
lib/Analysis/ScopInfo.cpp | ||
---|---|---|
619 ↗ | (On Diff #49190) | Does this work was well? assert(isa<MemIntrinsic>(getAccessInstruction())); |
lib/Analysis/ScopInfo.cpp | ||
---|---|---|
619 ↗ | (On Diff #49190) | if getAccessInstruction() return nullptr. assert(isa<MemIntrinsic>(MemAccInst(getAccessInstruction()))); Trigger an assertion failure. assert(isa<MemIntrinsic>(getAccessInstruction())); Trigger a SIGSEGV (suppose to ... no sure) Maybe we should write: assert(getAccessInstruction() && isa<MemIntrinsic>(getAccessInstruction())); |
lib/Analysis/ScopInfo.cpp | ||
---|---|---|
619 ↗ | (On Diff #49190) | isa<XYZ*>(nullptr) triggers the following assertion: assert(Val && "isa<> used on a null pointer"); in llvm/Support/Casting.h:81/88/95/102 |
lib/Analysis/ScopInfo.cpp | ||
---|---|---|
619 ↗ | (On Diff #49190) | ok |