efriedma added a comment. > The size you allocate here will presumably need to vary as the struct layout > changes, and you have no way of knowing which allocas will need their sizes > to be changed.
Your example is just a pointer; the size of a pointer won't change. That said, yes, address computation isn't the only place C cares about the layout of a struct. In particular variables (local or global) of struct type, sizeof(), and offsetof() need different handling. But I'm not sure how much any of those matter for BPF. > If this call is supposed to somehow represent that the %6 GEP is computed > from %5 by way of a struct field access, this will not be robust against any > kind of optimization: optimizations will happily rewrite uses of %6 to use %5 > or some other form directly, and you will have lost track of the pointers you > need to update. I think actually, the idea is that the intrinsic represents the computation of some additional adjustment, and so the following instructions use %7, the result of the call, not %6. So I think the existing formulation is sound. That said, it's awkward to have both an instruction and an intrinsic representing parts of the same offset computation; it probably makes sense to emit just the intrinsic, instead of both the intrinsic and the GEP, like you suggest. Repository: rC Clang CHANGES SINCE LAST ACTION https://reviews.llvm.org/D61809/new/ https://reviews.llvm.org/D61809 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
