[PATCH] unshare expressions in attribute arguments

Martin Sebor msebor@gmail.com
Mon Nov 23 18:51:20 GMT 2020


On 11/23/20 11:21 AM, Jakub Jelinek wrote:
> On Mon, Nov 23, 2020 at 11:08:13AM -0700, Martin Sebor wrote:
>>> I don't think it would be significant complication, on the other side you
>>> avoid wasting compile time memory on that (GC one, which means it will be
>>> wasted until GC collection if there is one ever).  Plus all the issues from
>>> having the same information in multiple different places.
>>
>> So just to make sure I understand correctly (and answer the question
>> I asked): unsharing the expression as in the proposed patch won't
>> cause any correctness issues.  You just find rewriting the code to
>> use the existing SAVE_EXPRs instead preferable for the reasons above.
>> Please correct me if I misunderstood something.
> 
> I admit I haven't looked into detail what exactly you are doing
> with those expressions.
> If they ever result in code generation rather than just warnings, then if
> they lack SAVE_EXPRs by the time you unshare, it would be a wrong-code
> (evaluating the expression multiple times).
> If they are just compared (lexicographically?), it can work, I guess a
> question is if foo () in two expressions is really equal, but I guess it
> would mean just one invocation of the same function and so can be considered
> equal.  Another thing is that one expression can call something and the
> other something else and just the user will know they will in that case do
> the same thing.  A warning (but not error) is fine in that case though.

Nontrivial expressions (anything but a straight PARM_DECL which is
mapped to a positional argument) are only used in lexicographical
comparisons to check for equivalence.  They're not used for codegen
decisions.

Examples can certainly be contrived where relying on equivalence is
not reliable and results in warnings for safe code.  There are even
very simple cases where this can happen that are clearly correct
(e.g., pr97548).  Some of the former are probably unavoidable (such
as the one you described) but I'd like to try to deal with at least
the basic ones.

Martin


More information about the Gcc-patches mailing list