Re: [PATCH] resubmitted for review to fix modulo scheduling. COMMITTED

[Kenneth Zadeck <zadeck at naturalbridge dot com>]

Bernd Schmidt wrote:
> Kenneth Zadeck wrote:
>> This is the nice piece of having something like df.  You can actually
>> define the problems that you want.  With the exception of urec, all of
>> the problems defined are really the textbook standard problems.  If you
>> want to see store store dependencies, then you should define a problem
>> where the this is such.
>
> What I'm concerned about is that these problems might not behave like
> their standard textbook versions in the presence of partial stores. 
> As far as I can tell, df-scan gathers the necessary uses and defs for
> partial accesses, so I think the special casing in the RU problem at
> least can (and should, to produce expected results) go away.
>
>
> Bernd
No it will not and it cannot.

A partial def means different things to different problems. 

In any problem where you are tracking the defs, a partial def is a real
def and needs to tracked as if it was a real def.  However, because it
is partial it does not kill the other defs that reach it. 

In any problem where you track uses, a partial def is just noise because
it cannot be a kill. 


If you are going to build a problem for something like scheduling, then
all of the uses and defs for a single web item need to retain their
orderings and so uses defs and partial defs would be treated in the same
way, as both kills and gens.

The reaching uses as defined is the text book definition.  You and I
could that either it is not useful or it is not appropriate for the task
it is currently being used for but this is in fact what modulo
scheduling expects.

We (and I go back to the original implemetation of df for my use of we)
implemented the textbook problems.  The current version of df is a lot
more precise about getting the little details and edges correct, but
they are true to the text book problems. 

We can either add more problems use the flags to modify the semantics if
the client needs something different.

On another issue, I actually think that RU is a silly and expensive
problem.  As I have said modulo scheduling is the only client, and if
this had not been there, I might have not implemented it.  RU is
expensive because you need a slot in the bit vectors for every use and
the bit vectors are not particularly sparse because it is common that
several uses for the same registrer are live any point.  The reaching
defs gives you the same info but pushes around far fewer bits.