> On Oct 23, 2023, at 2:43 PM, Siddhesh Poyarekar <siddh...@gotplt.org> wrote: > > On 2023-10-23 14:06, Martin Uecker wrote: >> We should aim for a good integration with the BDOS pass, so >> that it can propagate the information further, e.g. the >> following should work: >> struct { int L; char buf[] __counted_by(L) } x; >> x.L = N; >> x.buf = ...; >> char *p = &x->f; >> __bdos(p) -> N >> So we need to be smart on how we provide the size >> information for x->f to the backend. >> This would also be desirable for the language extension. > > This is essentially why there need to be frontend rules constraining > reordering and reachability semantics of x.L, thus restricting DSE and > reordering for it.
My understanding is that Restricting DSE and reordering should be done by the proper data flow information, with a new argument added to the BDOS call, this correct data flow information could be maintained, and then the DSE and reordering will not happen. I don’t quite understand what kind of frontend rules should be added to constrain reordering and reachability semantics? Can you explain this a little bit more? Do you mean to add some rules or requirment to the new attribute that the users of the attribute should follow in the source code? > This is not really a __bdos/__bos question, because that bit is trivial; if > the structure is visible, the value is simply x.L. This is also why adding a > reference to x.L in __bos/__bdos is not sufficient or even possible in, e.g. > the above case you note. I am a little confused here, are we discussing how to resolve the potential reordering issue of the following: " struct annotated { size_t foo; char array[] __attribute__((counted_by (foo))); }; p->foo = 10; size = __builtin_dynamic_object_size (p->array,1); “? Or a bigger issue? Qing > > Thanks, > Sid