Re: Data flow analysis

Chris F Clark <>
28 Jun 2004 20:00:12 -0400

          From comp.compilers

Related articles
Data flow analysis (2004-06-25)
Re: Data flow analysis (Matthew Danish) (2004-06-28)
Re: Data flow analysis (Chris F Clark) (2004-06-28)
Re: Data flow analysis (2004-06-28)
Data Flow Analysis (1991-06-11)
Data flow analysis (1992-04-14)
Data Flow Analysis (Ofer Ben-Ami) (1997-01-07)
| List of all articles for this month |

From: Chris F Clark <>
Newsgroups: comp.compilers
Date: 28 Jun 2004 20:00:12 -0400
Organization: The World Public Access UNIX, Brookline, MA
References: 04-06-093
Keywords: analysis
Posted-Date: 28 Jun 2004 20:00:12 EDT

Yes, things like you have described have been attempted. I'm not
aware of your specific example, but "Third Degree" a heap profiling
tool that I worked on as a consultant for Digital (became Compaq
became HPQ) did something very similar to what you are describing.

The essential problem is that you are maintinaing a database with one
entry per pixel (or group of pixels, as most code doesn't actually
write pixels, but writes icons, windows, scroll-bars, and other higher
level things). Now, each time some code in the application changes
those pixels, you need to update your database. However, some places
where the application looks like it might be changing pixels, it may
not be changing ownership. You can resolve that question using
dataflow analysis (unfortunately often abbreviated DFA), which will
allow you to "prove" that some section of code while modifying the
screen, is only modfying the same parts of the screen it has modified
before. Then, you know that you can move the computation of that
ownership (out of a loop) into a lower cost part of the code.

Your second more subtle question (about passing ownership through
different layers of the code) can be answered through a dataflow
analysis technique called "value propagation".

All that said, you may find as much information can be learned from
the graphic domain, as you are probably as likely to be interested in
bounding-boxes and overlaps as you are in code structure. as,
performance will probably be an issue. Once could keep a per pixel
representation of every pixel on the screen and update it at every
"instant", but the result would be an utter pig.

Hope this helps,

Chris Clark Internet :
Compiler Resources, Inc. Web Site :
23 Bailey Rd voice : (508) 435-5016
Berlin, MA 01503 USA fax : (978) 838-0263 (24 hours)

Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.