On Fri, Nov 03, 2023 at 02:32:04PM +0000, Qing Zhao wrote:
> > Why? It doesn't really matter. The options are
> > A. p is at &s.b[2] associated with &s.a and int type (or size of int
> > or whatever); .ACCESS_WITH_SIZE can't be pure,
>
> .ACCESS_WITH_SIZE will only load the size from its address, no any write to
> memory.
> It still can be PURE, right? (It will not be CONST anymore).
No, it can't be pure. Because for the IL purposes, it needs to be treated
as if it saves that address of the counter into some unnamed global variable
somewhere.
>
> > but sure, for aliasing
> > POV we can describe it with more detail that it doesn't modify anything
> > in the pointed structure, just escapes the pointer;
>
> If we need to do this, where in the gcc code we need to add these details?
I think ref_maybe_used_by_call_p_1/call_may_clobber_ref_p_1, but Richi is
expert here.
> > __bdos can stay
> > leaf I believe;
>
> That’s good! (I thought now _bdos will call .ACCESS_WITH_SIZE?)
No, it shouldn't call it obviously. If tree-object-size.cc discovery tracks
something to a pointer initialized by .ACCESS_WITH_SIZE call, then it should
I believe recurse on the first argument of that call (say if one has
ptr_3 = malloc (sz_1);
ptr_2 = .ACCESS_WITH_SIZE (ptr_3, &ptr_3[4], ...);
then supposedly __bdos later on should e.g. for 0/1 modes take minimum from
ptr_3 (the size actually allocated)) and the the counter.
Jakub
