This is an archive of the discontinued LLVM Phabricator instance.

CGCleanup: No need to do domination fixups for static allocas
ClosedPublic

Authored by GorNishanov on May 31 2017, 11:27 AM.

Details

Reviewers
rnk
rsmith
Summary

This is a follow up for the rL297084 which made sure that dominance is preserved during expression cleanup emission.
We ran into a case where dominance fixup code was inserting the store in the middle of allocas.

%x = alloca i32, align 4
store i32* %x, i32** %tmp.exprcleanup, align 4 ; <===== HERE
%ref.tmp3 = alloca %struct.A, align 1
%agg.tmp5 = alloca %"struct.std::experimental::coroutines_v1::coroutine_handle.0", align 4
%tmp.exprcleanup = alloca i32*, align 4
%allocapt = bitcast i32 undef to i32
store i32 %0, i32* %.addr, align 4

This fix make sure that domination fixup is not done static allocas.

(Alternative of https://reviews.llvm.org/D33663)

Diff Detail

Event Timeline

GorNishanov created this revision.May 31 2017, 11:27 AM
rnk added inline comments.May 31 2017, 12:07 PM
test/CodeGenCoroutines/coro-await-domination.cpp
33

It looks like this is the expression in question. This expression should have aggregate evaluation kind, not scalar. We don't need to reload aggregate expression evaluation results because they are represented with temporary allocas, and they don't have dominance problems. It seems like there is an incorrect call to PopCleanupBlocks somewhere, and that's where the real fix should be.

rnk accepted this revision.May 31 2017, 12:58 PM
rnk added inline comments.
test/CodeGenCoroutines/coro-await-domination.cpp
33

OK, nevermind. I found a way to reproduce this issue with gnu statement expressions, and after trying to fix it at a higher level, I decided the way you are fixing it is better. I went ahead and landed the fix along with my test cases. Please go ahead and land the coroutines test, though. More coverage is better.

This revision is now accepted and ready to land.May 31 2017, 12:58 PM
GorNishanov closed this revision.May 31 2017, 6:16 PM

Tested checked in. Thank you for looking into this, Reid!

r304380 = 1c0d15a4bf10876bb233e921907e114d52bee82e