kisslune / pocr Goto Github PK

Description

The solver only considers one of two parallel edges when these edges share the same EDGE_LABEL but have different LABEL_INDEX values.

Steps to Reproduce

1. Install POCR from commit dc9561d.

2. Create a file named gr1.cnf with the following content:

   S	call_i	ret_i
   
   Count:
   S
   

3. Create a file named g1.g with the following content:

   0	1	call_i	0
   0	1	call_i	1
   1	2	ret_i	0
   1	3	ret_i	1
   

4. Execute the command:

   cfl -pocr gr1.cnf g1.g -write-spairs output.txt

5. Open the output.txt file.

Expected Output

0	2
0	3

Actual Output

0	2

Dear author, thanks for the good work!

When I run cfl.cpp with StdCFL in a small test(art.peg), it quickly returns the result:

But running with Pocr_CFL, the program does not terminate(at least tens of seconds). By the way, in my case, the -pocr or -std seems not work, so I change the code manually to make it use Pocr_CFL.

Hi, it's a nice OOPSLA paper and I enjoy reading it. I wonder if you can provide the graph files of the programs mentioned in the OOPSLA paper. I understand that cpu2017 itself is not open source, so I just wonder if the graph files are available. Many thanks.

Thanks for the excellent code and good work~ I have a question about the preprocessing for the alias analysis.

Given the below input graph for Alias Analysis, the results of StdAA and PocrAA is inconsistent, where StdAA gives #SumEdges as 17 and PocrAA gives 11. When turning off the preprocessing, the results are consistent.

0	2	d
0	1	a
1	3	d

The preprocessed graph are given below, in which 0 and 1 are folded as 0. I guess the reason of inconsistency is, PocrAA use map<ID, ID> to store d since d is unique. But when the graph is folded(e.g., node 0 and 1), if the corresponding d edges(d<0, 2> <1,3>) are not folded, this assumption about "d is unique" no longer holds, so some edges may be overried.
In the other hand, StdAA use CFLData, which uses map<ID, NodeBS> to store d edges, so the behavior looks different from PocrAA.
If the d edges are not folded, I am not sure whether some reachability pairs may be lost. For example, since d<0,2> is overrided by d<0,3>, some edges rooted from 2 is not reachable from 0 via d<0,2>?

0	2	d
0	3	d

So I guess a possible solution would be folding the d edges as well? I notice in PEG::mergeNodeToRep(), the logic for folding "d edges" are provided but commented. I am curious that Is there any other consideration?

Also, if I want to reproduce the results of your OOPSLA paper, which version of graph should I use here(https://github.com/kisslune/CPU17-graphs)?

• aa-origin with the preprocessing turned on
• aa-simplified with the preprocessing turned off