> On Dec 3, 2025, at 01:43, Martin Uecker <[email protected]> wrote: > > Am Dienstag, dem 02.12.2025 um 21:21 +0000 schrieb Qing Zhao: >> >>> On Dec 2, 2025, at 15:56, Martin Uecker <[email protected]> wrote: >>> >>> >>> Hi Qing, >>> >>> Am Dienstag, dem 02.12.2025 um 20:33 +0000 schrieb Qing Zhao: >>>> Hi, Joseph and Martin: >>>> >>>> I am now working on PR96503 (attribute alloc_size effect lost after >>>> inlining) >>>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96503 >>>> >>>> My first major questions are: >>>> >>>> for the simple case in the PR: >>>> >>>> __attribute__ ((alloc_size (1))) int* f1 (int n) { return f (n); } >>>> >>>> void h1 (void) >>>> { >>>> int *p = f1 (3); >>>> __builtin_memset (p, 0, 3 * sizeof p); // missing warning >>>> } >>>> >>>> 1. where in the IR we should insert the call to the internal function >>>> .ACCESS_WITH_SIZE? >>>> >>>> My basic idea is: when the call to a routine marked with "alloc_size" >>>> attribute, generate a call to .ACCESS_WITH_SIZE for its assigned returned >>>> pointer. >>>> >>>> i.e, in the above example, when we see >>>> >>>> p = f1 (3) >>>> >>>> we will wrap the pointer "p" with .ACCESS_WITH_SIZE (p, 3, 0, 1), i.e, >>>> .ACCESS_WITH_SIZE (p, 3, 0, 1) = f1 (3); >>>> >>>> is this reasonable? >>> >>> My guess would be that this should be >>> >>> p = .ACCESS_WITH_SIZE(f1(3), 3, 0, 1); >> >> Our current design of .ACCESS_WITH_SIZE is: >> >> ACCESS_WITH_SIZE (REF_TO_OBJ, REF_TO_SIZE, >> TYPE_OF_SIZE + ACCESS_MODE, TYPE_SIZE_UNIT for element) >> which returns the REF_TO_OBJ same as the 1st argument; >> >> Therefore, the first argument of the routine “.ACCESS_WITH_SIZE” is the >> REF_TO_OBJ itself. > > How is the .ACCESS_WITH_SIZE discovered by BDOS > when you do the following? > > .ACCESS_WITH_SIZE (p, 3, 0, 1) = f1 (3); > use(p); // will BDOS find the information?
Not sure whether we need another version of .ACCESS_WITH_SIZE for the address of the pointer? ACCESS_WITH_SIZE_PTR ( &REF_TO_OBJ, REF_TO_SIZE, TYPE_OF_SIZE+ACCESS_MODE, TYPE_SIZE_UNIT for element) Which returns the address of the REF_TO_OBJ same as the 1st argument. Then for p = f1 (3); The IR will be: *(.ACCESS_WITH_SIZE_PTR (&p, 3, 0, 1)) = f1 (3); use (p); Gimplification phase will change it as: tmp = .ACCESS_WITH_SIZE_PTR (&p, 3, 0, 1); *tmp = f1 (3); use (*tmp); Then we need to update tree-object-size.cc <http://tree-object-size.cc/> to handle the new .ACCESS_WITH_SIZE_PTR correctly to get the size info. > > It isn't clear to me how this would work. > > And isn't the object we are talking about the pointed-to array, > so p would already be the ref itself. > >> >> For the “alloc_size” attribute, we can consider it as an “counted_by” >> attribute added >> to the “returned pointer” of the function call. > > Now the counted_by is attached to the FAM and we pass a > pointer to the FAM, so for me it seems we would need to pass > the pointer to the object we want to bound. > > For size we can create a temporary object, or we need another > version of .ACCESS_WITH_SIZE. Is the above new .ACCESS_WITH_SIZE_PTR similar as the one in your mind? thanks. Qing > > Martin > > >> So, adding the attribute to the pointer that is assigned by the returned >> value of the >> function is a reasonable approximation from my pointer of view. >> >> What do you think? > > > > >> >>> >>> or am I missing something? >>> >>>> >>>> 2. If the above idea is reasonable, where should I implement this in C FE? >>>> >>>> What’s in my mind is: where a function returned value is assigned to a >>>> pointer, >>>> checking whether the function type has “alloc_size” attribute, if so, >>>> wrapping >>>> The pointer that the function assigned to to a call to .ACCESS_WITH_SIZE. >>>> >>>> Which parts of the code, or which routines in C FE I should focus on? >>> >>> build_function_call_vec ? >> Thanks, will take a look at it. >> >> Qing >>> >>>> >>>> Let me know if you have any comments and suggestions. >>> >>> >>> Martin >>> >>>> >>>> Thanks a lot for your help.
