> On Oct 25, 2023, at 11:38 AM, Richard Biener <richard.guent...@gmail.com> > wrote: > > > >> Am 25.10.2023 um 16:50 schrieb Siddhesh Poyarekar <siddh...@gotplt.org>: >> >> 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. > > Btw, I’d like to see some hard numbers on the amount of extra false positives > this will cause a well as the effect on generated code before putting this in > mainline and effectively needing to support it forever.
What do you mean by the “extra false positives”? For the code generation impact: turning the original x.buf to a builtin function call __builtin_with_access_and_size(x,buf, x.L,-1) might inhibit some optimizations from happening before the builtin is evaluated into object size info (phase .objsz1). I guess there might be some performance impact. However, if we mark this builtin as PURE, NOTRROW, etc, then the negative performance impact will be reduced to minimum? Qing > > Richard > >> 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
