The dependency graph is computed after program transformations and (some) optimizations are performed. It could be the case that v4.9.4 is doing a better job at optimizing the code than v4.9.3 so that a procedure that was kept in the code by v4.9.3 has been eliminated by v4.9.4. It is hard to tell in your particular case which optimization is causing the issue.
Here’s a simple example:
$ cat dg.scm (declare (optimize-dead-definitions)) (declare (standard-bindings) (block) (inlining-limit 500))
(define (f x) (list x x))
(define (g x) (if x (f (list 1 x)) 42))
(define (h x) (list (f x) (g x)))
(pp (g #f)) $ gsc -c -expansion dg.scm Expansion:
(pp 42)
With v4.9.3 the expansion will include the definition of f, g and h even though none of those definitions are required by the code (due to procedure inlining).
Perhaps you could look at the difference in dependency graphs generated by v4.9.3 and v4.9.4 to find what is now considered dead that wasn’t in v4.9.3? This might point to an optimization you need to turn off to get the same result as v4.9.3 . The drop from 7178 to 6248 “reachable” procedures may simply be better inlining by the v4.9.4 compiler. Turning off inlining with a (declare (not inline)) may be all that is needed.
Marc
On Jan 4, 2022, at 5:02 AM, Sven Hartrumpf hartrumpf@gmx.net wrote:
Hello.
For a long time, I have been using gsc to determine all reachable bindings (functions and global variables) of a Scheme program with
gsc -c -dg foo.scm
This dependeny graph analysis is fast and was the most accurate one I found in the Scheme world. When stepping from 4.9.3 to 4.9.4(git), the analysis misses many reachable bindings (i.e. many false negatives, no false positives). For a large example program, the number drops from 7178 to 6248. Is this expected? Do I need to adjust my gsc options above?
Greetings Sven
Gambit-list mailing list Gambit-list@iro.umontreal.ca https://mailman.iro.umontreal.ca/cgi-bin/mailman/listinfo/gambit-list