On Dec 7, 2012, at 10:31 , Jordan Rose <[email protected]> wrote:

> 
> On Dec 7, 2012, at 10:27 , Ted Kremenek <[email protected]> wrote:
> 
>> On Dec 7, 2012, at 9:36 AM, Jordan Rose <[email protected]> wrote:
>>>>        // invalidate that region.  This is because a block may capture
>>>>        // a pointer value, but the thing pointed by that pointer may
>>>>        // get invalidated.
>>>> -        Store store = B.getRootWithoutRetain();
>>>> +        Store store = B.asImmutableMap().getRootWithoutRetain();
>>>>        SVal V = RM.getBinding(store, loc::MemRegionVal(VR));
>>> 
>>> This is an unfortunate impedance mismatch.
>> 
>> Impedance mismatch?  Please elucidate.
>> 
>>> 
>>> 
>>>> StoreRef RegionStoreManager::BindArray(Store store, const 
>>>> TypedValueRegion* R,
>>>> @@ -1724,9 +1813,9 @@
>>>> 
>>>>  // There may be fewer values in the initialize list than the fields of 
>>>> struct.
>>>>  if (FI != FE) {
>>>> -    RegionBindings B = GetRegionBindings(newStore.getStore());
>>>> -    B = addBinding(B, R, BindingKey::Default, svalBuilder.makeIntVal(0, 
>>>> false));
>>>> -    newStore = StoreRef(B.getRootWithoutRetain(), *this);
>>>> +    RegionBindingsRef B = getRegionBindings(newStore.getStore());
>>>> +    B = B.addBinding(R, BindingKey::Default, svalBuilder.makeIntVal(0, 
>>>> false));
>>>> +    newStore = StoreRef(B.asImmutableMap().getRootWithoutRetain(), *this);
>>>>  } 
>>> 
>>> Same impedance mismatch in BindStruct, BindVector, and BindArray. For that 
>>> matter, it's worse: we know that all the bindings will happen in a single 
>>> cluster.
>> 
>> Not sure what you mean by impedance mismatch.  I do agree that 
>> asImmutableMap().getRootWithoutRetain() chain is gross, and can be sugared 
>> up.  Is that what you mean?
> 
> In both cases, we're converting back and forth between Store(Ref) and 
> RegionBindingsRef. Before that was annoying but not a huge performance hit, 
> but now it means we're canonicalizing earlier than we otherwise would.

To make it clear, things haven't gotten worse than before. Your change just 
makes it clear that this is another area we ought to be able to make better.

_______________________________________________
cfe-commits mailing list
[email protected]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits

Reply via email to