This is an archive of the discontinued LLVM Phabricator instance.

[Analyzer] Extend exploded-graph-rewriter to support eq and diseq classes
Needs ReviewPublic

Authored by martong on Jun 25 2021, 7:26 AM.

Diff Detail

Event Timeline

martong created this revision.Jun 25 2021, 7:26 AM
martong requested review of this revision.Jun 25 2021, 7:26 AM
Herald added a project: Restricted Project. · View Herald TranscriptJun 25 2021, 7:26 AM
Herald added a subscriber: cfe-commits. · View Herald Transcript

LGTM, but I'm not really an expert in exploded-graph-rewriter. I think @NoQ should take a look.

clang/utils/analyzer/exploded-graph-rewriter.py
299

I believe that enumerate is more idiomatic for Python in situations like this.

NoQ added a comment.Jun 28 2021, 11:29 AM

Yay, great, thanks!

Can you add a test as well? We have a few in test/Analysis/exploded-graph-rewriter/ where we test parts of the emitted html.

Do you happen to have a screenshot of how it looks?

NoQ added a comment.Jun 28 2021, 12:51 PM

We have a few in test/Analysis/exploded-graph-rewriter/ where we test parts of the emitted html.

And they're now failing on the pre-merge buildbots. So i guess updating existing tests would already be nice.

martong updated this revision to Diff 356751.Jul 6 2021, 9:12 AM
  • Rebase on top of the newest version of the dependent patch
  • Draw borders for the table of the disequality info
  • Add tests

We have a few in test/Analysis/exploded-graph-rewriter/ where we test parts of the emitted html.

And they're now failing on the pre-merge buildbots. So i guess updating existing tests would already be nice.

Yeah, just updated the tests. Plus I added some new tests for the Eq/DisEq info.

Do you happen to have a screenshot of how it looks?

Yes! :)


I've added borders to the tables in the Disequality Info section, because the default rendering makes it hard to notice if there are multiple disequivalent classes attached to one class (see the second pics).

NoQ added a comment.Jul 6 2021, 5:24 PM

WDYT about the following format:

Equality constraints:
reg_$0<a> == reg_$1<b>
          == reg_$2<c>

Disequality constraints:
reg_$0<a> != reg_$3<d>,
          != reg_$4<e>

Comma is a bit hard to notice but otherwise kinda nicely readable?

WDYT about the following format:

Equality constraints:
reg_$0<a> == reg_$1<b>
          == reg_$2<c>

Disequality constraints:
reg_$0<a> != reg_$3<d>,
          != reg_$4<e>

Comma is a bit hard to notice but otherwise kinda nicely readable?

IMHO this format would be confusing if you have two SVals that include comparison operators:
E.g. SVal1 (reg_$1<int b>) == (reg_$2<int c>) and SVal2 (reg_$0<int a>) != 42. They might be in the same equivalence class, that would result this format:

Equality constraints:
(reg_$1<int b>) == (reg_$2<int c>) == (reg_$0<int a>) != 42

Well, ... I know the current table with the borders looks a bit rough and ugly, but I think the information is displayed in an obvious way and can be interpreted unambiguously.

NoQ added a comment.Jul 14 2021, 10:01 AM

We could color the special ==/!= 50% gray and/or replace it with a non-programming symbol such as ≃ and ≄.