Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Analyze across the call graph #8

Merged
merged 10 commits into from
Jun 12, 2024
Merged

Analyze across the call graph #8

merged 10 commits into from
Jun 12, 2024

Conversation

cceckman
Copy link
Owner

@cceckman cceckman commented May 10, 2024

...I think this does what it's supposed to.

For some reason, this is getting bogged down in the _loop analysis_
part of the per-function evaluation...eh? Weird.
The same pass (`FunctionBoundedTermination`) completes as expected when
invoked from a function-level transform pass
(`print<function-bounded-termination>`), but not when invoked from a
module-level transform pass `print<bounded-termination>`

Is this something weird with the proxy?
Several (all?) testdata files were failing when the
`FunctionTerminationPass` was run via proxy (from the module-level
pass), instead of being run at the function level. Unfortunately, "run
from the module" is the only way we think we can handle the call-graph
level analysis.

The symptom was LLVM stalling out -- looping forever? -- when we asked
for `ScalarEvolutionAnalysis`. I opened up LLDB and stepped through,
and... it was fine! Looking at `simple.c`, the pass produced results for
`get_value` and `main` just fine.

...but our functions are not the only functions listed in a module! For
instance, `simple.c` invokes `malloc`; as a result, `malloc` gets a
`declare`d in our module, without a function body. And *that's* where
the analysis was stalling out -- our pass was running on `F.getName() ==
"malloc"`!

Apparently, function-level passes are only run across functions
`define`d in the module -- but the listing of module contents includes
functions `define`d or `declare`d. I haven't really checked this, but it
is consistent with what we've seen, and would explain the difference
between running in function/module modes.

My fix (this commit) is to return `Unknown` if the function does not
have a body, i.e. has no basic blocks. This gets us back to a passing --
though incorrect -- state.
This doesn't propagate it back via the worklist, but it does tell us
about recursive loops.
@cceckman cceckman requested a review from anvayg June 10, 2024 19:08
@cceckman cceckman changed the title Reorder members to prepare for adding CGSCC Analyze across the call graph Jun 10, 2024
@anvayg anvayg merged commit bd9fe3a into main Jun 12, 2024
1 check passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants