On Mon, Oct 23, 2023 at 1:27 PM Siddhesh Poyarekar <siddh...@gotplt.org> wrote: > > On 2023-10-23 03:57, Richard Biener wrote: > > On Fri, Oct 20, 2023 at 10:41 PM Qing Zhao <qing.z...@oracle.com> wrote: > >> > >> > >> > >>> On Oct 20, 2023, at 3:10 PM, Siddhesh Poyarekar <siddh...@gotplt.org> > >>> wrote: > >>> > >>> On 2023-10-20 14:38, Qing Zhao wrote: > >>>> How about the following: > >>>> Add one more parameter to __builtin_dynamic_object_size(), i.e > >>>> __builtin_dynamic_object_size (_1,1,array_annotated->foo)? > >>>> When we see the structure field has counted_by attribute. > >>> > >>> Or maybe add a barrier preventing any assignments to array_annotated->foo > >>> from being reordered below the __bdos call? Basically an __asm__ with > >>> array_annotated->foo in the clobber list ought to do it I think. > >> > >> Maybe just adding the array_annotated->foo to the use list of the call to > >> __builtin_dynamic_object_size should be enough? > >> > >> But I am not sure how to implement this in the TREE level, is there a > >> USE_LIST/CLOBBER_LIST for each call? Then I can just simply add the > >> counted_by field “array_annotated->foo” to the USE_LIST of the call to > >> __bdos? > >> > >> This might be the simplest solution? > > > > If the dynamic object size is derived of a field then I think you need to > > put the "load" of that memory location at the point (as argument) > > of the __bos call right at parsing time. I know that's awkward because > > you try to play tricks "discovering" that field only late, but that's not > > going to work. > > > > A related issue is that assignment to the field and storage allocation > > are not tied together - if there's no use of the size data we might > > remove the store of it as dead. > > Maybe the trick then is to treat the size data as volatile? That ought > to discourage reordering and also prevent elimination of the "dead" store?
But we are an optimizing compiler, not a static analysis machine, so I fail to see how this is a useful suggestion. I think Martins suggestion to approach this as a language extension is more useful and would make it easier to handle this? Richard. > Thanks, > Sid
