IGVN worklist ordering

[Vladimir Kozlov]

One of the problems is that IGVN worklist is not "true" queue. There is no guarantee that nodes will be processed in the 
order they were placed on worklist. Long ago I played with "real" queue worklist but it bring only increase in memory 
consumption.

1. We only delay transformation when there are merge paths to wait when all paths are complete.

2. In reality you can't say that some path is dead until some data nodes and depending on them condition code are 
processed. We do try to eliminate dead nodes recursively when we find one - see remove_globally_dead_node() and 
kill_dead_code(). But it not always work.

Vladimir

On 12/23/15 3:07 PM, Krystal Mok wrote:
> Hi compiler team,
>
> I’d like to ask about the IGVN worklist ordering:
>
> 1. Is there a rule of thumb of which nodes should call record_for_igvn()? If so, in what order (e.g. data nodes vs.
> their control dependence)?
>
> Apparently, nodes that get a record_for_igvn() call right after their creation usually wants to delay the call to
> transform(), perhaps due to potential optimizations to their control input, or because they're created after parsing and
> might affect other nodes.
>
> But what would be a good list of guidelines about exactly what kind of nodes, or what kind of patterns in the IR, that
> should be considered as candidates to put onto the IGVN worklist, and vice versa?
>
> 2. Since it’s problematic for IGVN to process a node whose control path is already dead (but not yet collapsed to TOP),
> why isn’t there a mechanism built-in to IGVN’s worklist or PhaseIterGVN::transform_old() so that dead control paths
> always collapses before IGVN decides to process a node?
>
>
> I’ve had a doubt on this topic for quite a while now, so I’m seeking advice from all of you who have had to deal with
> bugs in this area.
> There have been a lot of bugs related to the IGVN worklist ordering in the past, the most of the fixes does either:
> a) add missing record_for_igvn() calls for problematic nodes
> b) switch the order of adjacent record_for_igvn() calls on related nodes
> Is it possible or a good idea to fix it down at the core of IGVN?
>
> Happy holidays, guys!
>
> Best regards,
> Kris