Re: Recognize valid paths

Hans-Peter Diettrich <DrDiettrich1@aol.com>
Sun, 24 Aug 2008 00:41:01 +0200

          From comp.compilers

Related articles
Recognize valid paths plfriko@yahoo.de (Tim Frink) (2008-08-20)
Re: Recognize valid paths m.helvensteijn@gmail.com (2008-08-23)
Re: Recognize valid paths DrDiettrich1@aol.com (Hans-Peter Diettrich) (2008-08-24)
Re: Recognize valid paths plfriko@yahoo.de (Tim Frink) (2008-08-26)
Re: Recognize valid paths plfriko@yahoo.de (Tim Frink) (2008-08-26)
Re: Recognize valid paths m.helvensteijn@gmail.com (Michiel Helvensteijn) (2008-08-27)
Re: Recognize valid paths jeffrey.kenton@comcast.net (Jeff Kenton) (2008-09-01)
| List of all articles for this month |

From: Hans-Peter Diettrich <DrDiettrich1@aol.com>
Newsgroups: comp.compilers
Date: Sun, 24 Aug 2008 00:41:01 +0200
Organization: Compilers Central
References: 08-08-042
Keywords: analysis
Posted-Date: 24 Aug 2008 14:42:17 EDT

Tim Frink schrieb:


> for some static program analyses it is crucial to recognize valid
> paths of the control flow graph taken while executing the code.
>
> if (x < 1)
> x = 1;
> if (x > 10)
> x = 10;
[...]
> I was wondering which compiler analyses might recognized such invalid
> combinations of paths. Any ideas?


Intuitively I'd partition the values of x into <1, 1..10 and >10, based
on the tested conditions. Then subdivide these ranges, when required by
modifications of the value in some branch (this will not happen in your
example). Finally I'd check whether for every partition a single path is
taken, what again is true in your example. If not, the analysis may
deserve more table space for the possible pathes. Another inspection of
the ever visited BB's, in all pathes, will reveal dead code - if this is
what you want to know. Otherwise I don't understand what an "invalid"
path (never taken) should be useful to know. Branch and bound (wikipedia)?


A more formal approach has already been posted.


DoDi


Post a followup to this message

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