|
Revision tags: llvmorg-18.1.8, llvmorg-18.1.7, llvmorg-18.1.6, llvmorg-18.1.5, llvmorg-18.1.4, llvmorg-18.1.3, llvmorg-18.1.2 |
|
| #
59ff3adc |
| 19-Mar-2024 |
martinboehme <mboehme@google.com> |
[clang][dataflow][NFC] Rename `ControlFlowContext` to `AdornedCFG`. (#85640)
This expresses better what the class actually does, and it reduces the
number of
`Context`s that we have in the codebase.
[clang][dataflow][NFC] Rename `ControlFlowContext` to `AdornedCFG`. (#85640)
This expresses better what the class actually does, and it reduces the
number of
`Context`s that we have in the codebase.
A deprecated alias `ControlFlowContext` is available from the old
header.
show more ...
|
|
Revision tags: llvmorg-18.1.1, llvmorg-18.1.0, llvmorg-18.1.0-rc4, llvmorg-18.1.0-rc3, llvmorg-18.1.0-rc2, llvmorg-18.1.0-rc1, llvmorg-19-init, llvmorg-17.0.6, llvmorg-17.0.5, llvmorg-17.0.4, llvmorg-17.0.3, llvmorg-17.0.2 |
|
| #
ed65ced2 |
| 20-Sep-2023 |
martinboehme <mboehme@google.com> |
[clang][dataflow] Identify post-visit state changes in the HTML logger. (#66746)
Previously, post-visit state changes were indistinguishable from
ordinary
iterations, which could give a confusing
[clang][dataflow] Identify post-visit state changes in the HTML logger. (#66746)
Previously, post-visit state changes were indistinguishable from
ordinary
iterations, which could give a confusing picture of how many iterations
a block
needs to converge.
Now, post-visit state changes are marked with "post-visit" instead of an
iteration number:
)
show more ...
|
|
Revision tags: llvmorg-17.0.1, llvmorg-17.0.0, llvmorg-17.0.0-rc4, llvmorg-17.0.0-rc3, llvmorg-17.0.0-rc2 |
|
| #
e6cd409f |
| 02-Aug-2023 |
Martin Braenne <mboehme@google.com> |
[clang][dataflow] In `ControlFlowContext`, handle `Decl` by reference instead of pointer.
`build()` guarantees that we'll always have a `Decl`, so we can simplify the code.
Reviewed By: ymandel, xa
[clang][dataflow] In `ControlFlowContext`, handle `Decl` by reference instead of pointer.
`build()` guarantees that we'll always have a `Decl`, so we can simplify the code.
Reviewed By: ymandel, xazax.hun
Differential Revision: https://reviews.llvm.org/D156859
show more ...
|
|
Revision tags: llvmorg-17.0.0-rc1, llvmorg-18-init, llvmorg-16.0.6, llvmorg-16.0.5, llvmorg-16.0.4, llvmorg-16.0.3, llvmorg-16.0.2, llvmorg-16.0.1, llvmorg-16.0.0, llvmorg-16.0.0-rc4 |
|
| #
48f97e57 |
| 24-Feb-2023 |
Sam McCall <sam.mccall@gmail.com> |
[FlowSensitive] Log analysis progress for debugging purposes
The goal is to be able to understand how the analysis executes, and what its
incremental and final findings are, by enabling logging and
[FlowSensitive] Log analysis progress for debugging purposes
The goal is to be able to understand how the analysis executes, and what its
incremental and final findings are, by enabling logging and reading the logs.
This should include both framework and analysis-specific information.
Ad-hoc printf-debugging doesn't seem sufficient for my understanding, at least.
Being able to check in logging, turn it on in a production binary, and quickly
find particular analysis steps within complex functions seem important.
This can be enabled programmatically through DataflowAnalysisOptions, or
via the flag -dataflow-log. (Works in unittests, clang-tidy, standalone
tools...)
Important missing pieces here:
- a logger implementation that produces an interactive report (HTML file)
which can be navigated via timeline/code/CFG.
(I think the Logger interface is sufficient for this, but need to prototype).
- display of the application-specific lattice
- more useful display for the built-in environment
(e.g. meaningful & consistent names for values, hiding redundant variables in
the flow condition, hiding unreachable expressions)
Differential Revision: https://reviews.llvm.org/D144730
show more ...
|