> On Oct 25, 2023, at 10:50 AM, Siddhesh Poyarekar <siddh...@gotplt.org> wrote: > > On 2023-10-25 09:27, Qing Zhao wrote: >>> On Oct 24, 2023, at 7:56 PM, Siddhesh Poyarekar <siddh...@gotplt.org> wrote: >>> >>> On 2023-10-24 18:51, Qing Zhao wrote: >>>> Thanks for the proposal! >>>> So what you suggested is: >>>> For every x.buf, change it as a __builtin_with_size(x.buf, x.L) in the >>>> FE, then the call to the _bdos (x.buf, 1) will >>>> Become: >>>> _bdos(__builtin_with_size(x.buf, x.L), 1)? >>>> Then the implicit use of x.L in _bdos(x.buf.1) will become explicit? >>> >>> Oops, I think Martin and I fell off-list in a subthread. I clarified that >>> my comment was that any such annotation at object reference is probably too >>> late and hence not the right place for it; basically it has the same >>> problems as the option A in your comment. A better place to reinforce such >>> a relationship would be the allocation+initialization site instead. >> I think Martin’s proposal might work, it’s different than the option A: >> A. Add an additional argument, the size parameter, to __bdos, >> A.1, during FE; >> A.2, during gimplification phase; >> Option A targets on the __bdos call, try to encode the implicit use to the >> call, this will not work when the real object has not been instantiation at >> the call site. >> However, Martin’s proposal targets on the FMA array itself, it will enhance >> the FAM access naturally with the size information. And such FAM access with >> size info will propagated to the __bdos site later through inlining, etc. >> and then tree-object-size can use the size information at that point. At the >> same time, the implicit use of the size is recorded correctly. >> So, I think that this proposal is natural and reasonable. > > Ack, we discussed this later in the thread and I agree[1]. Richard still has > concerns[2] that I think may be addressed by putting __builtin_with_size at > the point where the reference to x.buf escapes, but I'm not very sure about > that. > > Oh, and Martin suggested using __builtin_with_size more generally[3] in > bugzilla to address attribute inlining issues and we have high level > consensus for a __builtin_with_access instead, which associates access type > in addition to size with the target object. For the purposes of counted_by, > access type could simply be -1.
Yes, I read all the discussions in the comments of PR96503 (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96503), and I do agree that this is a good idea. I prefer the name for the new builtin as: __builtin_with_access_and_size Instead of __builtin_with_access All the attributes, “alloca_size”, “access”, and the new “counted_by” for FMA, could be converted to this builtin consistently, and even the later new extension, for example, “counted_by” attribute for general pointers, could use the same builtin. SOMETYPE *ptr = __builtin_with_access_and_size (SOMETYPE *ptr, size_t size, int access) In the above, 1. SOMETYPE will be the type of the pointee of “ptr”, it could be a real type or void. 2. “size” If SOMETYPE is a real type, the “size” will be the number of elements of the type; If SOMETYPE is void, the “size” will be the number of bytes. 3. “access” -1: Unknown access semantics 0: none 1: read_only 2: write_only 3: read_write For the “counted_by” and “alloca_size” attribute, the “access” will be -1. Qing > > Thanks, > Sid > > > [1] > https://inbox.sourceware.org/gcc-patches/73af949c-3caa-4b11-93ce-3064b95a9...@gotplt.org/T/#m4f3cafa489493180e258fd62aca0196a5f244039 > > [2] > https://inbox.sourceware.org/gcc-patches/73af949c-3caa-4b11-93ce-3064b95a9...@gotplt.org/T/#mcf226f891621db8b640deaedd8942bb8519010f3 > > [3] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96503#c6
