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

[Bernd Schmidt <bernds_cb1 at t-online dot de>]

Kenneth Zadeck wrote:
> Df_problems.c utilizes and abstraction that df-scan maintains: uses are
> uses and defs are defs.  I will admit that I did not document this
> abstraction but it is consistently maintained.  If a def is partial,
> that means that some of the bits that entered the def survive.  If this
> instruction looks at any of the bits, either the ones destroyed or the
> ones passed thru, then a use should have be generated in df-scan, but if
> the scanning did not produce a use, it is not the place of the code in
> df-problems, which does not look at the instructions, (I know this is
> violated in the urec problem, but as I said before, we are trying to get
> rid of that) to infer one.
>
> In this problem we are trying to find which uses reach (in a backwards
> sense) each point of the program. 
>
> The question asked in the ru problem is does this def stop the uses and
> the answer is that if it is partial, then it does not.

> Let us say that I was going to build a dead code elimination algorithm
> on this problem.  And lets say that I had an instruction, I2,  that has
> two sets, a full one to A and a partial one to B.
> Lets say that A is used after this instruction and B is dead.  This
> makes I2 live.  Can I delete an instruction I1 that that is before I2
> that sets B?  I would contend that I can.   In your world I cannot.

That's a special case of a more general issue.  It's really no different 
than

  I1: B = fish (42, 3.1415);
  I2: A = 19, B = B | 15;
  ... A live, B dead ...

It's really not the fact that the write to B is partial (so is an IOR), 
but the fact that the the parallel set of B in insn I2 is dead, so we'd 
delete it if we could, and this would make the set I1 dead as well.  To 
be able to track this consistently would require tracking uses and defs 
by elts of a parallel rather than by insn.

IOW, the partial-ness of the write is merely an implementation detail, 
and I'd argue the representation is wrong if it doesn't show a use of B 
in I2.

Now, for dead-code elimination it may be advantageous to special-case 
partial sets this way, but I wonder about other potential uses of this 
code that might want to see a partial write as a read-write operation. 
Building in knowledge of the users of the information into a general 
dataflow problem seems like a layering violation.

> The fact that this is what the modulo sched people are trying to do is
> somewhat problematic.  They could have done a lot better just defining a
> dataflow problem to do the dependency analysis rather than screwing
> around with 3 or 4 dataflow problems that are not really what they
> wanted.  However, since this is just an optional pass that apparently
> only works on one platform, and the person who wrote it is no longer
> doing gcc, this may not be that much of a problem.

Hmm.  I assume ia64 is that one platform it works on?  Why does it only 
work there; did it never work elsewhere or is it unmaintained and 
suffering from bitrot?  It doesn't sound like a very good idea to have a 
generic optimization that only works on one platform.


Bernd