deduplicating lambda methods

[Vicente Romero]

On 03/17/2018 03:00 PM, Brian Goetz wrote:
>
>
>>> I don't think we want to be duplicating the constant folding logic 
>>> in multiple places, but I also don't think we have to -- doesn't L2M 
>>> run after constant folding already?  I ask because I've already seen 
>>> constant propagation turn capturing lambdas into noncapturing.
>>
>> I don't think we need to duplicate the constant folding logic for 
>> this, I just think that the hasher and the differ should be blind 
>> regarding the substructure of a tree as soon as a constant is found, 
>> be it in a variable or as the constant value of a tree. Liam has a 
>> good point, if our new constant folding phase were rewriting the 
>> trees then the differ and the hasher he is proposing would have this 
>> for free. I guess that this is a use case that can make us consider 
>> doing tree rewriting as part of the new constant folding phase, but 
>> we are not doing it right now, only for some trees: basically ldc() 
>> indy() and condys. That's why I was saying that considering constants 
>> in the tree differ / hasher could wait and that it don't have to be 
>> part of this patch.
>>
>
> When you say blind, obviously it has to take the constants into account, 

right but it doesn't have to redo what constant folding is doing, the 
constant will be already there sitting in the tree,

> since x -> x+2 and x->x+3 are different lambdas.  I think for now, not 
> trying to do anything special here is the right move;

I totally agree that's why I started saying that this could be a 
follow-up development

> this could conceivably fail to deduplicate x -> x + 2  and x -> x + 
> TWO  when TWO is a static final, but that's an acceptable loss, since 
> deduplication is merely optimistic.

right it would fail to do that, but it could probably handle it by 
adding a couple of LOC more compared to the current patch, but again I'm 
not proposing to do it now

>
>
>