On 2023-10-23 08:34, Richard Biener wrote:
A related issue is that assignment to the field and storage allocation
are not tied together - if there's no use of the size data we might
remove the store of it as dead.
Maybe the trick then is to treat the size data as volatile? That ought
to discourage reordering and also prevent elimination of the "dead" store?
But we are an optimizing compiler, not a static analysis machine, so I
fail to see how this is a useful suggestion.
Sorry I didn't meant to suggest doing this in the middle-end.
I think Martins suggestion to approach this as a language extension
is more useful and would make it easier to handle this?
I think handling for this (e.g. treating any storage allocated for the
size member in the struct as volatile to prevent reordering or
elimination) would have to be implemented in the front-end, regardless
of whether it is a language extension or as a gcc attribute. How would
making it a language extension vs a gcc attribute make it different?
Thanks,
Sid
