[PATCH] D76526: Add an algorithm for performing "optimal" layout of a struct.

Xun Li via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Mon May 3 16:47:07 PDT 2021


lxfind added inline comments.


================
Comment at: llvm/include/llvm/Support/OptimalLayout.h:40
+      : Offset(FixedOffset), Size(Size), Id(Id), Alignment(Alignment) {
+    assert(Size > 0 && "adding an empty field to the layout");
+  }
----------------
rjmccall wrote:
> lxfind wrote:
> > rjmccall wrote:
> > > aykevl wrote:
> > > > This line is triggered in the coroutine lowering passes, see: https://bugs.llvm.org/show_bug.cgi?id=49916
> > > > 
> > > > I don't know whether this is a bug in OptimizedStructLayout or in the coroutine lowering passes, but I'm noting it here just in case.
> > > Hmm.  Abstractly it seems like a reasonable precondition, so it's probably best to fix in the coroutine lowering passes.
> > I guess we could explicitly check for the size of Alloca in corosplit, and if it's 0, don't put it on the frame?
> It depends on what semantics we need to provide for the alloca.  If the address needs to be consistent and unique throughout the coroutine, which I think is the usual `alloca` guarantee, then coroutine lowering should probably ask layout for something as if the object had size 1.
Curious, would it just work if we remove this assertion?
That would still allow the alloca to have a consistent address and I cannot think of a reason this algorithm will fail because a field is 0 size?


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D76526/new/

https://reviews.llvm.org/D76526



More information about the llvm-commits mailing list