Re: [PATCH] unshare expressions in attribute arguments

[Martin Sebor <msebor@gmail.com>]

On 11/23/20 10:30 AM, Jakub Jelinek wrote:
> On Mon, Nov 23, 2020 at 10:03:44AM -0700, Martin Sebor wrote:
>>> If the most significant bound is lost, why don't you save in the attribute
>>> early only the most significant bound before it is lost
>>
>> The other bounds are a part of the type so saving them in the attribute
>> isn't essential.  I save all of them because it simplifies their lookup.
>> With only the most significant bound in the attribute argument, looking
>> up the other bounds (e.g., when checking function redeclarations for
>> mismatches) will, in addition to doing what's done for the most
>> significant bound, involve scanning the declarations' argument lists,
>> extracting the bounds from the SAVE_EXPRs, before comparing them.
>> As an example, in
>>
>>    void f (int A[m][n]);
>>
>> the attribute has the chain (VAR_DECL(m), VAR_DECL(n)) as arguments
>> and comparing them with another declaration of f is as simple as
>> traversing the chain and comparing each node value.
>>
>> With the change you suggest, the attribute will only have VAR_DECL(m)
>> and the least significant bound will have to be extracted from A[m]'s
>> type's size which is:
>>
>>    MULT (NOP (bitsizetype, NOP (sizetype, SAVE (VAR (n)))), 32)
>>
>> It's possible to do but not without some additional complexity and
>> cost.
> 
> 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.

Thanks
Martin