> On Dec 3, 2025, at 14:48, Martin Uecker <[email protected]> wrote:
> 
> Am Mittwoch, dem 03.12.2025 um 15:52 +0000 schrieb Qing Zhao:
>> 
>>> 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?
> 
> I still do not understand why it couldn't be just
> 
> p = .ACCESS_WITH_SIZE_PTR(f1(3), 3);

Thinking this again, I guess the major concern with this approach might be the 
interaction with inlining transformation. 

Inlining transformation usually happens in the earlier stages of the middle 
end, and the call 
to .ACCESS_WITH_SIZE_PTR is kept till the end of middle-end. 

Then the question is: should we allow the inlining of “f1(3)” inside 
.ACCESS_WITH_SIZE_PTR(f1(3), 3)?

I think we should allow this, then, will there be any issue with inlining and 
after inlining?

Need more study on this direction. I will take a further study on this 
direction anyway.

thanks.

Qing
> 
> but I haven't really looked at this in detail.
> 
> Martin
> 
>> 
>> 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.


Reply via email to