Maciej Fijalkowski wrote:

...

more refactoring&simplification: don't track the constness of nodes, as nobody is using it so far. The idea is that optimizatons relying on the constness should be done during the optimize_operation phase, not during the find_node phase. I'm not 100% sure this will cover all possible case though, so maybe we will need to reintroduce this later.

That is a bit of a problem, since a lot of things can only happen if constant folding was already done. A good example is a guard_value followed by getarrayitem_gc. getarrayitem_gc needs to have constant index for anything like virtuals or virtualizables. If it's a non-constant index, nodes will be incorrect (you cannot delay putting stuff in it's dictionary).

uhm, now that I read that port of optimize.py more carefully, I think you are right. It's a bit unfortunate that we need two almost identical features in two different places, though :-/

Maciej Fijalkowski wrote:

...

more refactoring&simplification: don't track the constness of nodes, as nobody is using it so far. The idea is that optimizatons relying on the constness should be done during the optimize_operation phase, not during the find_node phase. I'm not 100% sure this will cover all possible case though, so maybe we will need to reintroduce this later.

That is a bit of a problem, since a lot of things can only happen if constant folding was already done. A good example is a guard_value followed by getarrayitem_gc. getarrayitem_gc needs to have constant index for anything like virtuals or virtualizables. If it's a non-constant index, nodes will be incorrect (you cannot delay putting stuff in it's dictionary).

uhm, now that I read that port of optimize.py more carefully, I think you are right. It's a bit unfortunate that we need two almost identical features in two different places, though :-/