Svadev mailing list

[John Criswell <criswell AT illinois.edu>]

On 1/29/13 12:27 PM, Daniel Huang wrote:

Yes, all the nodes are completely folded. I just filed the bug-report under the SAFEcode project in the LLVM bugzilla. Thanks for the help.

Daniel, can you also file bugs for some of the poolalloc assertions?  I recommend filing a single bug for each different assertion that you see.

Which problem is more problematic for you at the moment: the DNode folding or the poolalloc assertions?

Also, if you haven't already, you should re-run the analysis at -O0 or -O1 to see if that improves the type-inference.  Depending on what is causing the collapsing of the DSNodes, the fix may be really, really easy or very difficult.

-- John T.

Regards,

Dan

On Tue, Jan 29, 2013 at 8:33 AM, Adve, Vikram Sadanand <vadve AT illinois.edu> wrote:

I suspect that the reasons are either 1 or 3.  Please file bug reports so we have your examples and we'll bump this up in priority.

--Vikram

On Jan 28, 2013, at 10:24 AM, "John Criswell" <criswell AT illinois.edu> wrote:

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.

_______________________________________________
svadev mailing list
svadev AT cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/svadev