deduplicating lambda methods

[Maurizio Cimadamore]

On 17/03/18 18:57, Vicente Romero wrote:
>
>
> On 03/17/2018 02:49 PM, Brian Goetz wrote:
>>
>>>>
>>>>     Also, as a bonus, consider constant expressions, we probably want:
>>>>     return 5; and return 2 + 3; to be equal.
>>>>
>>>>     I think that these two use cases will need a "normalization" step
>>>>     to be
>>>>     applied to the tree and store in the map, set, only a normalized
>>>>     version
>>>>     of the tree. I understand that at least considering constants 
>>>> could be
>>>>     out of the scope of this patch, so I can see it as a follow up
>>>>     development.
>>
>> 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.
I think this is where I see things going as well - as I said, right now 
we kind of handle folding in different places - it's not a lot of lines 
of code - but there are lines scattered in quite few places where things 
have to be special cased if a type happens to be constant - this is true 
for the FreeVarCollector in Lower, which is also subclassed by the 
collector in L2M. If we had an early step such as the one we are 
envisioning for the condy-folding effort which _reifies_ folding choices 
in the AST (rather than resorting to special types), it would be much 
more straightforward for the remaining pieces of the pipeline to just do 
the 'right thing'.

That said, until we get there I also agree with what Vicente says: 
visitors should not descend into constant values - and that probably 
includes the hasher/differ visitors. But we should mark this special 
code for 'removal' for when things will be handled in a more uniform 
fashion.

Also, a side note: we have learned during condy-folding that rewriting 
trees is not always the right approach - if you are compiling with -g, 
you might need the trees to remain in place (as you want the compiler to 
perform less aggressive folding) - so I'm not sure the compiler will 
always be able to rely on constants to be rewritten in the constant 
folding phase.

Maurizio