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
Event Timeline
Thanks for this! Two nits and a question
lib/Analysis/MemorySSAUpdater.cpp | ||
---|---|---|
487 ↗ | (On Diff #211961) | nit: if it's straightforward to turn this into a static helper, please do so. |
538 ↗ | (On Diff #211961) | NewUseOrDef should always be non-null, no? |
test/Analysis/MemorySSA/loop-rotate-simplified-clone.ll | ||
2 ↗ | (On Diff #211961) | ; REQUIRES: asserts |
Address comments.
lib/Analysis/MemorySSAUpdater.cpp | ||
---|---|---|
538 ↗ | (On Diff #211961) | No, this can now be null. |
lib/Analysis/MemorySSA.cpp | ||
---|---|---|
1690 ↗ | (On Diff #212383) | 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 ↗ | (On Diff #211961) | 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. :) |