On 1/26/13 5:14 PM, Daniel Huang wrote:
Hi Svadev,
I've been running SAFEcode on small input code that uses all memory objects in a type-homogenous manner. In this case, I except the DSnodes to have very explicit type information. However, I've noticed that most of the DSnodes created during the
pool allocation pass have no type information.
By no type information, I assume you mean that the DSNode is folded (i.e., the isNodeCompletelyFolded() method returns true)? Is this correct?
There are a number of reasons why DSA may not be giving you type information for something that is type safe:
1) Since DSA was written, some LLVM optimizations have been changed to transform typed GEPs into byte-indexing GEPs. DSA can't infer that the GEP indexes the memory object in a type-consistent manner, so it folds the DSNode.
2) One or more fields appear to be used in a type-inconsistent fashion. As a result, two pointers to DSNodes of different types get merged, causing their DSNodes to get merged.
3) DSA conservatively finds an aliasing relationship that appears type-inconsistent.
In addition, SAFECode will consider a DSNode type-inconsistent if:
1) The DSNode has the Int2Ptr, Ptr2Int, or Unknown flags set (that implies that DSA might have missed aliases through casts or other funky instructions).
2) The DSNode has the External flag set (as external code may not treat the DSNode in a type-consistent fashion).
3) The DSNode has overlapping fields at different offsets (e.g., a 4-byte word at offset 0 overlaps a 1-byte access at offset 3).
I suggest that you try using DSA before some of the optimizations are run (try to use clang with -O0 or -O1) to see if you get better type-inference results. Reducing optimization is bad for the SAFECode compiler but seems reasonable for the work with your
type-checker.
I checked to see if they were unknown nodes, but that wasn't the case either. Furthermore, when running SAFEcode with pool-allocation on medium sized (~200lines) C programs, it usually crashes with some assertion failure. What is the state of
the pool-allocation library in SAFEcode?
As mentioned previously, the pool allocation code is not enabled by default in SAFECode because it is not sufficiently robust. I don't know how robust it is because I don't use it with SAFECode presently.
When you see an assertion in poolalloc, please file a bug report at
http://llvm.org/bugs. The bug report should include a test case (preferably a reduced test case) and directions on reproducing the error. We'll see your bug report and try to fix it as quickly as our schedules permit.
-- John T.
