On Sun, 10 Dec 2023, Jason Merrill wrote:
> On 12/10/23 05:22, Richard Biener wrote:
> >> Am 09.12.2023 um 21:13 schrieb Jason Merrill <ja...@redhat.com>:
> >>
> >> On 11/2/23 21:18, Nathaniel Shead wrote:
> >>> Bootstrapped and regtested on x86-64_pc_linux_gnu.
> >>> I'm not entirely sure if the change I made to have destructors clobber
> >>> with
> >>> CLOBBER_EOL instead of CLOBBER_UNDEF is appropriate, but nothing seemed to
> >>> have
> >>> broken by doing this and I wasn't able to find anything else that really
> >>> depended on this distinction other than a warning pass. Otherwise I could
> >>> experiment with a new clobber kind for destructor calls.
> >>
> >> It seems wrong to me: CLOBBER_EOL is documented to mean that the storage is
> >> expiring at that point as well, which a (pseudo-)destructor does not imply;
> >> it's perfectly valid to destroy an object and then create another in the
> >> same storage.
> >>
> >> We probably do want another clobber kind for end of object lifetime. And/or
> >> one for beginning of object lifetime.
> >
> > There?s not much semantically different between UNDEF and end of object but
> > not storage lifetime? At least for what middle-end optimizations do.
>
> That's fine for the middle-end, but Nathaniel's patch wants to distinguish
> between the clobbers at beginning and end of object lifetime in order to
> diagnose stores to an out-of-lifetime object in constexpr evaluation.
Ah, I see. I did want to add CLOBBER_SOL (start-of-life) when working
on PR90348, but I always fail to finish working on that stack-slot sharing
issue. But it would be for the storage life, not object life, also
added by gimplification.
> One option might be to remove the clobber at the beginning of the constructor;
> are there any useful optimizations enabled by that, or is it just pedantically
> breaking people's code?
It's allowing DSE to the object that was live before the new one. Not
all objects require explicit destruction (which would get you a clobber)
before storage can be re-used.
> > EOL is used by stack slot sharing and that operates on the underlying
> > storage, not individual objects live in it.
>
> I wonder about changing the name to EOS (end of storage [duration]) to avoid
> similar confusion with object lifetime?
EOS{L,D}? But sure, better names (and documentation) are appreciated.
Richard.
