So, based on the discussion so far, We will define the .ACCESS_WITH_SIZE as following:
.ACCESS_WITH_SIZE (REF_TO_OBJ, REF_TO_SIZE, ACCESS_MODE) INTERNAL_FN (ACCESS_WITH_SIZE, ECF_LEAF | ECF_NOTHROW, NULL) which returns the “REF_TO_OBJ" same as the 1st argument; 1st argument “REF_TO_OBJ": Reference to the object; 2nd argument “REF_TO_SIZE”: Reference to size of the object referenced by the 1st argument, if the object that the “REF_TO_OBJ” refered has a * real type, the SIZE that the “REF_TO_SIZE” referred is the number of the elements of the type; * void type, the SIZE that the “REF_TO_SIZE” referred is number of bytes; 3rd argument "ACCESS_MODE": -1: Unknown access semantics 0: none 1: read_only 2: write_only 3: read_write NOTEs, A. This new internal function is intended for a more general use from all the 3 attributes, "access", "alloc_size", and the new "counted_by", to encode the "size" and "access_mode" information to the corresponding pointer. (in order to resolve PR96503, etc. https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96503) B. For "counted_by" and "alloc_size" attributes, the 3rd argument will be -1. C. In this wrieup, we focus on the implementation details for the "counted_by" attribute. However, this function should be ready to be used by "access" and "alloc_size" without issue. Although .ACCESS_WITH_SIZE is not PURE anymore, but it’s only read from the 2nd argument, and not modify anything in the pointed objects. So, we can adjust the IPA alias analysis phase with this details (ref_maybe_used_by_call_p_1/call_may_clobber_ref_p_1). One more note: only the integer type is allowed for the SIZE, and in tree_object_size.cc, all the SIZE (in attributes “access”, “alloc_size”, etc) are converted to “sizetype”. So, we don’t need to specify The type of the size for “REF_TO_SIZE” since it’s always integer types and always converted to “sizetype” internally. Let me know any more comment or suggestion. Qing On Nov 3, 2023, at 2:32 AM, Martin Uecker <uec...@tugraz.at> wrote: > > > Am Freitag, dem 03.11.2023 um 07:22 +0100 schrieb Jakub Jelinek: >> On Fri, Nov 03, 2023 at 07:07:36AM +0100, Martin Uecker wrote: >>> Am Donnerstag, dem 02.11.2023 um 17:28 -0700 schrieb Bill Wendling: >>>> On Thu, Nov 2, 2023 at 1:36 PM Qing Zhao <qing.z...@oracle.com> wrote: >>>>> >>>>> Thanks a lot for raising these issues. >>>>> >>>>> If I understand correctly, the major question we need to answer is: >>>>> >>>>> For the following example: (Jakub mentioned this in an early message) >>>>> >>>>> 1 struct S { int a; char b __attribute__((counted_by (a))) []; }; >>>>> 2 struct S s; >>>>> 3 s.a = 5; >>>>> 4 char *p = &s.b[2]; >>>>> 5 int i1 = __builtin_dynamic_object_size (p, 0); >>>>> 6 s.a = 3; >>>>> 7 int i2 = __builtin_dynamic_object_size (p, 0); >>>>> >>>>> Should the 2nd __bdos call (line 7) get >>>>> A. the latest value of s.a (line 6) for it’s size? >>>>> Or B. the value when the s.b was referenced (line 3, line 4)? >>>>> >>>> I personally think it should be (A). The user is specifically >>>> indicating that the size has somehow changed, and the compiler should >>>> behave accordingly. >>> >>> >>> One potential problem for A apart from the potential impact on >>> optimization is that the information may get lost more >>> easily. Consider: >>> >>> char *p = &s.b[2]; >>> f(&s); >>> int i = __bdos(p, 0); >>> >>> If the compiler can not see into 'f', the information is lost >>> because f may have changed the size. >> >> 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, 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; __bdos can stay >> leaf I believe; and when expanding __bdos later on, it would just >> dereference the associated pointer at that point (note, __bdos is >> pure, so it has vuse but not vdef and can load from memory); if >> f changes s.a, no problem, __bdos will load the changed value in there > > Ah, I right. Because of the reload it doesn't matter. > Thank you for the explanation! > > Martin > >> B. if .ACCESS_WITH_SIZE associates the pointer with the s.a value from that >> point, .ACCESS_WITH_SIZE can be const, but obviously if f changes s.a, >> __bdos later will use s.a value from the &s.b[2] spot
