This patch is to address https://bugs.llvm.org/show_bug.cgi?id=49916.
When the size of an alloca is 0, it will trigger an assertion in OptimizedStructLayout when being added to the frame.
Fix it by not adding it at all. We return index 0 (beginning of the frame) for all 0-sized allocas.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
Can you test this with some code that doesn't bitcast the zero-sized alloca before its use? Just slightly worried that we might assert because of the type difference.
Assuming that that isn't a problem, LGTM.
llvm/test/Transforms/Coroutines/coro-zero-alloca.ll | ||
---|---|---|
64–81 | The checks for foo.resume fails in my environment. My output was: define internal fastcc void @foo.resume(%foo.Frame* noalias nonnull align 8 dereferenceable(24) %FramePtr) { entry.resume: %vFrame = bitcast %foo.Frame* %FramePtr to i8* %a1.reload.addr = getelementptr inbounds %foo.Frame, %foo.Frame* %FramePtr, i64 0, i32 2 %a4.reload.addr = getelementptr inbounds %foo.Frame, %foo.Frame* %FramePtr, i64 0, i32 3 %a0.reload.addr = bitcast %foo.Frame* %FramePtr to [0 x i8]* %a4.cast = bitcast i16* %a4.reload.addr to i8* %a1.cast = bitcast i32* %a1.reload.addr to i8* tail call void @usePointer(i8* nonnull %vFrame) tail call void @usePointer(i8* nonnull %a1.cast) tail call void @usePointer(i8* nonnull %vFrame) tail call void @usePointer(i8* nonnull %vFrame) tail call void @usePointer(i8* nonnull %a4.cast) tail call void @usePointer2([0 x i8]* nonnull %a0.reload.addr) tail call void @free(i8* nonnull %vFrame) ret void } It also looks good without failing to match. |
llvm/test/Transforms/Coroutines/coro-zero-alloca.ll | ||
---|---|---|
64–81 | That's strange. Seems the frame placement isn't deterministic? |
llvm/test/Transforms/Coroutines/coro-zero-alloca.ll | ||
---|---|---|
64–81 | a3.cast is a redundant bitcast, which some passes will eliminate. Maybe the test is accidentally testing more than just the result of the split pass? |
llvm/test/Transforms/Coroutines/coro-zero-alloca.ll | ||
---|---|---|
64–81 | My bad. It looks like I pollute my code locally. After I cloned a new version, everything looks good. |
llvm/test/Transforms/Coroutines/coro-zero-alloca.ll | ||
---|---|---|
64–81 | I think that this test still fails: https://lab.llvm.org/buildbot/#/builders/123/builds/3751 On my RHEL7, it also fails. |
llvm/test/Transforms/Coroutines/coro-zero-alloca.ll | ||
---|---|---|
64–81 | ping |
llvm/test/Transforms/Coroutines/coro-zero-alloca.ll | ||
---|---|---|
64–81 | It is really interesting. I fix this problem by cloning a new clean LLVM source. Did you try that? |
llvm/test/Transforms/Coroutines/coro-zero-alloca.ll | ||
---|---|---|
64–81 | It is still failing on my machine. |
llvm/test/Transforms/Coroutines/coro-zero-alloca.ll | ||
---|---|---|
64–81 | Do you test this with upstream or downstream? It is OK in trunk in my machine. |
llvm/test/Transforms/Coroutines/coro-zero-alloca.ll | ||
---|---|---|
64–81 | upstream |
llvm/test/Transforms/Coroutines/coro-zero-alloca.ll | ||
---|---|---|
64–81 | Let me simplify the test so it doesn't run the entire O2 |
The checks for foo.resume fails in my environment. My output was:
It also looks good without failing to match.