[PATCH] D21613: [DSE] Avoid iterator invalidation bugs by deferring deletion.
Chad Rosier via llvm-commits
llvm-commits at lists.llvm.org
Fri Jun 24 07:24:08 PDT 2016
mcrosier added a comment.
In http://reviews.llvm.org/D21613#465710, @eli.friedman wrote:
> Oh, I see what you mean about the http://reviews.llvm.org/rL273141 testcase; I thought the stores in the testcase were ordered differently. You run into the issue I was describing if you reorder the last two stores, like this:
>
> store i32 4, i32* @g_31, align 1, !dbg !20
> %_tmp16.i.i = load volatile i16*, i16** @g_30, align 1, !dbg !28
> %_tmp17.i.i = load i16, i16* %_tmp16.i.i, align 1, !dbg !28
> store i16 %_tmp17.i.i, i16* @g_118, align 1, !dbg !20
> store i16 0, i16* @g_118, align 1, !dbg !43
> store i32 0, i32* @g_31, align 1, !dbg !31
>
>
> ---
Yes, I believe we'll miss this case if we defer the deletion of aliasing loads/stores. Let me see if I can take your suggested approach of deleting non-phi nodes, @eli.friedman. Also, can you please explain why the phi nodes must stick around (at least in the short term)? I don't follow..
Alternatively, I'm wondering if we could use @dberlin's suggestion from http://reviews.llvm.org/D21076 and utilize the iterator that is returned by BB->eraseFromParent() to address the iterator problem.
> The primary point of http://reviews.llvm.org/rL273141 is that DSE shouldn't change behavior based on the presence of debug info... so as long as you're not breaking that invariant, it should be fine to modify/delete the testcase as necessary.
AFAICT, this implementation won't suffer from this problem, so I'm thinking it would be okay to drop the test.
http://reviews.llvm.org/D21613
More information about the llvm-commits
mailing list