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

[John McCall via Phabricator via llvm-commits]

rjmccall 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");
+  }
----------------
lxfind wrote:
> 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?
The assertion is there because I don't want this library to have to start making policy decisions like that.  You can very easily handle zero-sized allocas that don't have to have a unique address by assigning them an offset of zero within the frame.  It looks like `alloca` doesn't guarantee a unique address, so that should be fine.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D76526