LoopRotate may simplify instructions, leading to the new instructions not having memory accesses created for them.
Allow this behavior, by allowing the new access to be null when the template is null, and looking upwards for the proper defined access when dealing with simplified instructions.
Details
Diff Detail
- Repository
- rL LLVM
- Build Status
Buildable 35692 Build 35691: arc lint + arc unit
Event Timeline
Address comments.
lib/Analysis/MemorySSAUpdater.cpp | ||
---|---|---|
538 | No, this can now be null. |
lib/Analysis/MemorySSA.cpp | ||
---|---|---|
1690 | This new optionality is surprising to me, and I think something that's not generally desirable for users of this function. Would it make sense to refactor this slightly into something like tryCreateDefinedAccess and createDefinedAccess? (the try version being the body of this function without the assert(NewAccess != nullptr), and the create literally just being try + the assert) Alternatively, I'd be happy with an added bool CreationMustSucceed = true param that stands in for the new if (Template) conditional, if you feel that's better. | |
lib/Analysis/MemorySSAUpdater.cpp | ||
538 | Oh, right. I was looking at my source without the patch applied when thinking about this question. This is what I get for reviewing CLs late -- sorry. :) |
This new optionality is surprising to me, and I think something that's not generally desirable for users of this function. Would it make sense to refactor this slightly into something like tryCreateDefinedAccess and createDefinedAccess? (the try version being the body of this function without the assert(NewAccess != nullptr), and the create literally just being try + the assert)
Alternatively, I'd be happy with an added bool CreationMustSucceed = true param that stands in for the new if (Template) conditional, if you feel that's better.