Re: [PATCH 1/2] Come up with function_decl_type and use it in tree_function_decl.

[Marc Glisse <marc.glisse@inria.fr>]

On Wed, 3 Jul 2019, Richard Biener wrote:

> On July 3, 2019 4:53:30 PM GMT+02:00, "Martin Liška" <mliska@suse.cz> wrote:
>> On 7/2/19 7:15 PM, Marc Glisse wrote:
>>> On Tue, 2 Jul 2019, Martin Liška wrote:
>>>
>>>> After the discussion with Richi and Nathan, I made a place in
>> tree_function_decl
>>>> and I rebased the original Dominik's patch on top of that.
>>>
>>> So, last time there were some questions about the legality of this
>> transformation. Did you change the exact set of functions on which this
>> is applied?
>>
>> Yes. I was not included in the original discussion, but I hope the
>> transformation is valid.
>> Btw. clang also removes the new/delete pairs and I guess it was the
>> original motivation of the patch.
>
> We also remove malloc/free pairs which the C standard does not explicitly allow (but also doesn't explicitly forbid). I don't think standards need to enumerate everything allowed and I don't know any explicit wording in the C++ standard that forbids this.

The C++ standard has explicit wording allowing to remove new-delete pairs 
in some circumstances (expr.new, allocator.members), so I would assume 
that other circumstances are forbidden (not that I care much, I am just 
afraid someone might).

The patch apparently has DECL_IS_OPERATOR_DELETE only on the replaceable 
global deallocation functions, not all delete operators, contrary to 
DECL_IS_OPERATOR_NEW, so the name is misleading. On the other hand, those 
seem to be the ones for which the optimization is legal (well, not quite, 
the rules are in terms of operator new, and I am not sure how well 
operator delete has to match, but close enough).

> It's only that users can override the allocation functions (but so can 
> they in C) and it was suggested we need to preserve side effects unknown 
> to the compiler.

-- 
Marc Glisse