Lei,
Just to make this a little clearer, suppose we had:
unsigned factorial(unsigned n) {
if (n == 0)
return 1;
return n * factorial(n - 1);
}
Currently when we analyze this function, we create only one LocationContext.
However, one way to do IPA is to due inlining of function calls. In this case,
we might create a second LocationContext during the first recursive call to
factorial. If we wanted to further inline, we might create a second
LocationContext, etc., each one capturing the "context" of the recursive call
and simulating an abstract stack frame (obviously bounding the amount of
LocationContexts we create).
On Apr 11, 2011, at 10:53 AM, Ted Kremenek wrote:
> I thought about this some more, and using the LocationContext might be a
> reasonable place to put checker-specific data that represents "global"
> information (i.e not specific to a GRState) but also limited in scope (i.e.
> the data is limited to the scope of analyzing a given *call* to a function).
> Once we support analysis inlining, it will be possible for multiple
> LocationContext objects to be around at the once for the same function. Are
> the statistics you are interested in specific to a given LocationContext?
>
> On Apr 11, 2011, at 10:19 AM, Ted Kremenek <[email protected]> wrote:
>
>> Hi Lei,
>>
>> LocationContext should not contain any checker-specific data. It is only
>> intended to model context-sensitivity (i.e., it simulates an abstract stack
>> frame, or "location" in an abstract call chain).
>>
>> What are you trying to do?
>>
>> Ted
>>
>> On Apr 10, 2011, at 8:26 PM, 章磊 wrote:
>>
>>> Hi Clang,
>>>
>>> This patch add a DenseMap to record the CheckedReturn count for a
>>> functiondecl(fielddecl, vardecl as function pointer) in LocationContext.
>>>
>>> ImmutableMap seems not alright here, is DenseMap ok?
>>>
>>> And how to make it checker-specific?
>>>
>>> This patch is preparation for statistical UncheckedRenturn checker.
>>> I'll appreciate it if there are any advice about this patch.
>>>
>>> --
>>> Best regards!
>>>
>>> Lei Zhang
>>> <CRResultMap.patch>_______________________________________________
>>> cfe-commits mailing list
>>> [email protected]
>>> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
>>
>>
>> _______________________________________________
>> cfe-commits mailing list
>> [email protected]
>> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
_______________________________________________
cfe-commits mailing list
[email protected]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
