The relations primitive_type, integer_type, fp_type, etc. are generated by the FactGenerator, but they also have rules in the Datalog code. This situation should at the very least be documented, but possibly changed so that only one of the two is responsible for adding facts to these relations.
Advantages to doing it in Datalog:
We know statically that there will be at least a few primitives types: i1, float, etc. Perhaps Souffle and Clang can take advantage of this when these are stated as facts and generate better code.
Advantages of doing it in the FactGenerator:
We account for only and exactly the types that actually appear in the module at hand
Less Datalog code leads to smaller synthesized C++ code, which means lower compile times
Also, I think this might be tied up with a difference in the output of cclyzer++ in the ntu-uaf.c test case, but I'm not sure exactly how.
The relations
primitive_type,integer_type,fp_type, etc. are generated by the FactGenerator, but they also have rules in the Datalog code. This situation should at the very least be documented, but possibly changed so that only one of the two is responsible for adding facts to these relations.Advantages to doing it in Datalog:
i1,float, etc. Perhaps Souffle and Clang can take advantage of this when these are stated as facts and generate better code.Advantages of doing it in the FactGenerator:
Also, I think this might be tied up with a difference in the output of cclyzer++ in the
ntu-uaf.ctest case, but I'm not sure exactly how.