Ken Lesniak wrote:
>
> >Could someone please explain what this function is supposed to do? It
>
> For public functions, you can (usually) get a descrption from the
> cooresponding header:
>
> * OP *TN_Reaching_Value_At_Op(TN *tn, OP *op, DEF_KIND *kind,
> * BOOL reaching_def)
> * The routine can be used to find (1) the reaching definition of
> * operand <tn> of <op>, or (2) the following use of the result <tn>
> * of <op>. The knob is controlled by the flag <reaching_def>.
> * If <reaching_def> is TRUE, find the reaching definition of the <tn>,
> * if <reaching_def> is FALSE, find the reaching use of the <tn>.
> * If none is found, return NULL. <kind> determines the definition kind
> * property returned by the function, i.e if the value definition
> * of <tn> is VAL_KNOWN, VAL_UNKNOWN, VAL_COND_DEF, VAL_COND_USE, .. etc.
> *
> * Note that not all reaching definitions are found, dominator
> * information is necessary to handle more cases and it's not
> * proven to be worth it.
> *
>
> >seems like it is trying to find the unique instruction that defines or
> >uses the value of a TN from a given position by tracing through OP lists
> >and BB lists. However, there are questionable lines with comments like:
> > if (cur_bb == bb) continue; // ignore self successor
> >which seem to indicate that definitions or uses inside single block
> >loops are skipped. Why is this done?
>
> I originally wrote this function because I was trying to do some simple
> optimizations (detecting division by constant for example). Others
> (no longer with sgi) greatly enhanced it for their purposes, so I no
> longer fully understand it either.
>
> I would have to assume however that the check for a self successor
> is to avoid endlessly re-examining the same BB.
>
That's what I thought too, but it seems to be a very poor way of doing
it. First of all, it's completely broken for cases where a TN is defined
both inside and outside of a 1-block loop because it thinks the outside
definition is the only one. This causes problems in CFLOW because it
thinks some TN has constant value when it really doesn't. Second, it
does nothing to avoid loops of more than one block.
The check might be okay when searching forward for uses of a TN,
although it might still skip uses inside loops that may be important,
but this is definitely not okay when searching backwards for
definitions. Perhaps the check should be modified to look at the
live_def set instead of the live_out set.
|