This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH] Fix missed DSE opportunity with operator delete.
- From: Richard Biener <richard dot guenther at gmail dot com>
- To: Marc Glisse <marc dot glisse at inria dot fr>
- Cc: Jason Merrill <jason at redhat dot com>, Mikhail Maltsev <maltsevm at gmail dot com>, gcc-patches mailing list <gcc-patches at gcc dot gnu dot org>
- Date: Tue, 26 Apr 2016 12:35:01 +0200
- Subject: Re: [PATCH] Fix missed DSE opportunity with operator delete.
- Authentication-results: sourceware.org; auth=none
- References: <5712AF84 dot 5080002 at gmail dot com> <CAFiYyc2wz_a-92BbvMGa5mtUtWTgk2wafxWmmzum1r_t-_-vnw at mail dot gmail dot com> <5716998B dot 8010907 at gmail dot com> <CAFiYyc0NdjRjuvJKr5ZHhnAEc0zaDAktSCZES9M3FPRqmciSXg at mail dot gmail dot com> <571A999E dot 7060704 at gmail dot com> <CAFiYyc2XA=qRsTgvuFohuw-6kwVrp1W+sDqhbjqV-uei9EY=yQ at mail dot gmail dot com> <CADzB+2neZpNEfDZoCcBoGtDz0MairJ+KnniBbcPRpQPzYy0=fA at mail dot gmail dot com> <CAFiYyc3Gv0GTZn1MEkUWhvMu0r=nSt2y8k8qLovONVrz_ckYJQ at mail dot gmail dot com> <alpine dot DEB dot 2 dot 20 dot 1604261117040 dot 2084 at laptop-mg dot saclay dot inria dot fr>
On Tue, Apr 26, 2016 at 11:28 AM, Marc Glisse <marc.glisse@inria.fr> wrote:
> On Tue, 26 Apr 2016, Richard Biener wrote:
>
>> On Mon, Apr 25, 2016 at 9:57 PM, Jason Merrill <jason@redhat.com> wrote:
>>>
>>> Hmm, this seems to assume that operator delete itself doesn't do
>>> anything with the object being deleted. This is true of the default
>>> implementation, but I don't see anything in the standard that
>>> prohibits a user-supplied replacement or class-specific deallocation
>>> function from accessing the memory.
>>
>>
>> Hmm, but the delete expression invokes the (default) destructor which
>> ends the lifetime of the object and thus invalidates all memory. Don't
>> we place a CLOBBER there as well nowadays (seems not).
>>
>> For
>>
>> struct A { A(); ~A(); int i; };
>>
>> int main()
>> {
>> A *a = new A;
>> delete a;
>> }
>>
>> I see
>>
>> struct A * a;
>> <<cleanup_point <<< Unknown tree: expr_stmt
>> (void) (a = TARGET_EXPR <D.2346, operator new (4)>;, try
>> {
>> A::A ((struct A *) D.2346);
>> }
>> catch
>> {
>> operator delete (D.2346);
>> }, (struct A *) D.2346;) >>>>>;
>> <<cleanup_point <<< Unknown tree: expr_stmt
>> if (SAVE_EXPR <a> != 0B)
>> {
>> A::~A (SAVE_EXPR <a>);, operator delete ((void *) SAVE_EXPR <a>);;
>> }
>> else
>> {
>> <<< Unknown tree: void_cst >>>
>> } >>>>>;
>>
>> so after the destructor is invoked the objects lifetime ends.
>
>
> You can also call operator new and operator delete directly in C++, not just
> through new/delete expressions, and that's what std::allocator does.
>
> Especially in C++17 where we should have aligned allocation, I can imagine
> operator new / delete implemented like gcc/config/i386/gmm_malloc.h on some
> platforms, which requires reading in operator delete stuff that operator new
> wrote there. Depending on inline decisions, DSE-ing part of new could be
> problematic (IIRC those functions are technically not allowed to be marked
> 'inline', but that's not quite the same thing).
Ok. Is it then a matter of also seeing the size of the object and only treating
[p, p + size[ as DCEable thus only the object itself becomes dead?
Btw, similar issues would arise if we'd inline malloc() from glibc and that used
a malloc annotated internal helper and we run into a (not inlined) free() call.
Richard.
> --
> Marc Glisse