Go: Stratify CFG::succ to avoid recursion
#15162
Conversation
|
Happy to take suggestions for a better name to replace |
The first level doesn't deal with defer statements properly. The second level usees the first level to deal with them properly.
owen-mc
force-pushed
the
go/stratify-cfg-succ
branch
from
3e82259
to
9697d76
Compare
|
Performance testing shows no change on the normal set of repos but a big speedup on the two repos that we noticed the original performance problem on: analysis time went from 1304s to 298s on one and 950s to 228s on the other. I don't think we need a full QA run, but I can do one if requested. |
| @@ -2074,6 +2080,12 @@ module CFG { | |||
| ) | |||
| } | |||
|
|
|||
| /** Gets a successor of `nd`, that is, a node that is executed after `nd`. */ | |||
There was a problem hiding this comment.
Mention what the Simple variant omits
![github-advanced-security[bot]](https://web.archive.org/web/20240111220402im_/https://avatars.githubusercontent.com/in/57789?s=60&v=4){kind=small}
There was a problem hiding this comment.
Indeed there's no need for the private top-level predicate to be cached. As part of a recursive definition along with the member succ0s it should also be nomagic because context from succ including nextDefer etc is harmful to introduce anywhere in the recursion.
This was introduced by a copy-paste error
|
DCA shows no change in performance for the normal repos and the expected speed-ups for the two affected repos (maybe even slightly better - because of to |
The first level doesn't deal with defer statements properly. The second level uses the first level to deal with them properly.