> On Aug 17, 2023, at 1:49 PM, Siddhesh Poyarekar <siddh...@gotplt.org> wrote: > > On 2023-08-17 09:58, Qing Zhao wrote: >>> So this is a (sort of) known issue, which necessitated the early_objsz pass >>> to get an estimate before a subobject reference was optimized to a MEM_REF. >> Do you mean that after a subobject reference was optimized to a MEM_REF, >> there is no way to compute the size of the subobject anymore? > > Yes, in cases where the TYPE_SIZE is lost and there's no other allocation > information to fall back on.
Okay, I see. > >>> However it looks like the MIN/MAX hack doesn't work in this case for >>> OST_MINIMUM; it should probably get the minimum of the two passes if both >>> passes were successful, or only the result of the pass that was successful. >> You mean that the following line: >> 2053 enum tree_code code = object_size_type & OST_MINIMUM ? MAX_EXPR : >> MIN_EXPR; >> Might need to be changed to: >> 2053 enum tree_code code = MIN_EXPR; > > Yes, that's it. Maybe it's more correct if instead of MAX_EXPR if for > OST_MINIMUM we stick with the early_objsz answer if it's non-zero. I'm not > sure if that's the case for maximum size though, my gut says it isn't. So, the major purpose for adding the early object size phase is for computing SUBobjects size more precisely before the subobject information lost? Then, I think whatever MIN or MAX, the early phase has more precise information than the later phase, we should use its result if it’s NOT UNKNOWN? Qing > > Thanks, > Sid
