I went over this section, and found a couple of places where
the old definition still lurked in the paper, so I've
changed those.
Following a brief discussion with Laurie, I've also updated
the account of reweaving in 4.2.1 substantially, also
replacing the figure.
Let me know what you think!
-O
On Tue, 12 Apr 2005, Ondrej Lhotak wrote:
> On Sat, Apr 09, 2005 at 08:35:32PM +0200, Damien Sereni wrote:
> > > 8) Damien mentioned a variation of our inter-proc algorithm ... Damien ...
> > > what was it - something about not needed something on "all paths"?
> >
> > I just noticed in chicago that the condition for setting a cflow
> > residue to alwaysMatch is stronger than it needs to be -
> >
> > what i would expect would be
> > a query shadow qsh is statically true if for every interprocedural
> > path p to qsh there is an update shadow in p
> > [where an interprocedural path includes calls but not returns]
> >
> > whereas the condition that there is an update shadow sh such that qsh
> > is in mustCflow(sh) is equivalent to :
> > every interprocedural path p to qsh goes through sh [ie all paths must
> > go through the same shadow]
> >
> > (please check that i haven't made some mistake along the way!)
> >
> > I guess the mustCflow version is probably easier / more efficient to
> > compute, but maybe we should mention the other one (of course, the
> > benchmarks show the mustCflow is precise enough)
>
> I've updated the discussion of mustcflow in the paper to match the
> code (which implements the improved condition which Damien describes
> above) and checked it in. I'd appreciate it if someone had a look at the
> discussions of mustcflow to make sure that they make sense.
>
> Ondrej
>
> >
> > Cheers,
> > Damien
> >
>
Received on Thu Apr 14 16:19:12 2005
This archive was generated by hypermail 2.1.8 : Fri Apr 15 2005 - 02:10:06 BST