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.

Of course I guess __bos then behaves like sizeof ().

Richard.

>
> Qing
>
> >
> > It may not work for something like this though:
> >
> > static size_t
> > get_size_of (void *ptr)
> > {
> >  return __bdos (ptr, 1);
> > }
> >
> > void
> > foo (size_t sz)
> > {
> >  array_annotated = __builtin_malloc (sz);
> >  array_annotated = sz;
> >
> >  ...
> >  __builtin_printf ("%zu\n", get_size_of (array_annotated->foo));
> >  ...
> > }
> >
> > because the call to get_size_of () may not have been inlined that early.
> >
> > The more fool-proof alternative may be to put a compile time barrier right 
> > below the assignment to array_annotated->foo; I reckon you could do that 
> > early in the front end by marking the size identifier and then tracking 
> > assignments to that identifier.  That may have a slight runtime performance 
> > overhead since it may prevent even legitimate reordering.  I can't think of 
> > another alternative at the moment...
> >
> > Sid
>

Reply via email to