Re: heads and tails

[Ondrej Lhotak <olhotak@sable.mcgill.ca>]

We should define heads and tails differently. They should be all
possible entry/exit points, respectively. For heads, we would have the
first instruction (even if there is a goto to it), and the start of
every exception handler (because they are like entry points, in that
the flow into them is not explicit in the graph) (this is only in the
brief unit graph). For tails, we would have all return statements, and,
presumably, all statements that can throw an exception. I suspect this
last one will cause problems...

Ondrej

On Mon, Apr 29, 2002 at 11:35:42PM -0400, Florian Loitsch wrote:
> hi,
> When using the provided Analysis-classes, one just overwrites
> the newInitialFlow() and customizeInitialFlowGraph() to assing the
> desired flowsets to each unit. customizeInitialFlowGraph() is used, if
> the heads/tails should have different sets.
> Take as example a "defined-Locals"-analysis (similary to what Javac
> does).
> we assign the full set to each unit except the heads, where we put the
> empty set.
> if we did this using the current implementation of UnitGraph.java we
> would, imo, run into troubles: heads, according to this class, are
> units, that have no predecessor. but we could have a "goto" back to
> this first unit. in this case we may not even have heads... Therefore
> we wouldn't find any non-initialized variable.
> 
> while i haven't yet encountered this problem with heads, i've had it
> with tails: if we have an infite loop, we will not have a tail
> neither.
> The problem is, that even fixing the UnitGraph.java so the first
> element is always a head, will not fix the tails. and what is the tail
> of an infite loop?
> any suggestions?
> mfg
>  florian loitsch
> -- 
> People who think they know everything are very irritating to those of us who do.
> - Anon.
>