> On Oct 23, 2023, at 2:43 PM, Siddhesh Poyarekar <[email protected]> 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
