This is an archive of the discontinued LLVM Phabricator instance.

[clang][dataflow] Relax assumption that `AggregateStorageLocations` correspond to struct type.
AbandonedPublic

Authored by ymandel on Jun 3 2022, 10:01 AM.

Details

Reviewers
xazax.hun
sgatev
Summary

Currently, when an AggregateStorageLocation is mapped to a StructValue, we
enforce that it's type is a struct or class. However, we don't need this to hold
and there are reasonable violations of this assumption -- for example, using the
StructValue for its properties, while modeling a non-struct type.

This patch removes the assertion.

Diff Detail

Event Timeline

ymandel created this revision.Jun 3 2022, 10:01 AM
Herald added a project: Restricted Project. · View Herald TranscriptJun 3 2022, 10:01 AM
ymandel requested review of this revision.Jun 3 2022, 10:01 AM
Herald added a project: Restricted Project. · View Herald TranscriptJun 3 2022, 10:01 AM

Does this mean you want to use StructValues for non-struct types to have access to properties? I wonder if it would be a cleaner approach to be able to assign properties to any type of values instead of weakening the type system. E.g., properties could be a table on the side, a mapping from any kind of values to a set of properties.

Does this mean you want to use StructValues for non-struct types to have access to properties? I wonder if it would be a cleaner approach to be able to assign properties to any type of values instead of weakening the type system. E.g., properties could be a table on the side, a mapping from any kind of values to a set of properties.

Indeed! That would definitely be an improvement. This was motivated by actual crashes in the existing code which relied on this feature. It's fair to say that the assertion was trying to enforce reasonable behavior (just not *required*). We definitely we need a more general properties mechanism. I could put in a FIXME to put back the assert pending that change, but I'm generally hesitant about assertions that don't enforce necessary properties (only "nice"). Ideally, we'd have a way to log places (say, debug only) where we hit a surprising but not illegal condition.

xazax.hun accepted this revision.Jun 3 2022, 11:09 AM

I'm generally hesitant about assertions that don't enforce necessary properties (only "nice").

I think not enforcing this in the current model is OK. I am more concerned about the future if we plan to run multiple checks/modeling in the same fixed point iteration. One check might make the assumption that the types are matching up while the other can end up producing values where this is not the case.

This revision is now accepted and ready to land.Jun 3 2022, 11:09 AM

using the StructValue for its properties, while modeling a non-struct type.

Could you explain the use case in more details? Maybe a better change is to move synthetic properties to the base class Value?

using the StructValue for its properties, while modeling a non-struct type.

Could you explain the use case in more details?

A StructValue is used to model a complex underlying type for access to its properties, but the corresponding AggregateStorageLocation is not initialized with a record type -- specifically, the real and complex type -- because that type is irrelevant to the model.

Maybe a better change is to move synthetic properties to the base class Value?

In part, indeed that's what Gabor suggested above. Please see my response earlier and let me know what you think.

I'm generally hesitant about assertions that don't enforce necessary properties (only "nice").

I think not enforcing this in the current model is OK. I am more concerned about the future if we plan to run multiple checks/modeling in the same fixed point iteration. One check might make the assumption that the types are matching up while the other can end up producing values where this is not the case.

Good point -- but I think this gets at a larger issue of how to handle multiple models touching the same type. Even if the types align, for example, the properties might not. So, we need an overall story.

With properties moved up in the hierarchy this could be abandoned now, right?

ymandel abandoned this revision.Jun 17 2022, 10:16 AM

With properties moved up in the hierarchy this could be abandoned now, right?

Yes, I think that would be best. Thanks for the reminder!