This is an archive of the discontinued LLVM Phabricator instance.

[clang][dataflow] Don't associate prvalue expressions with storage locations.
ClosedPublic

Authored by mboehme on Aug 28 2023, 4:51 AM.

Details

Summary

Instead, map prvalue expressions directly to values in a newly introduced map Environment::ExprToVal.

This change introduces an additional member variable in Environment but is an overall win:

  • It is more conceptually correctly, since prvalues don't have storage locations.
  • It eliminates complexity from Environment::setValue(const Expr &E, Value &Val).
  • It reduces the amount of data stored in Environment: A prvalue now has a single entry in ExprToVal instead of one in ExprToLoc and one in LocToVal.
  • Not allocating StorageLocations for prvalues additionally reduces memory usage.

This patch is the last step in the migration to strict handling of value categories (see https://discourse.llvm.org/t/70086 for details). The changes here are almost entirely internal to Environment.

The only externally observable change is that when associating a RecordValue with the location returned by Environment::getResultObjectLocation() for a given expression, callers additionally need to associate the RecordValue with the expression themselves.

Diff Detail

Event Timeline

mboehme created this revision.Aug 28 2023, 4:51 AM
Herald added a project: Restricted Project. · View Herald Transcript
mboehme requested review of this revision.Aug 28 2023, 4:51 AM
Herald added a project: Restricted Project. · View Herald TranscriptAug 28 2023, 4:51 AM
Herald added a subscriber: cfe-commits. · View Herald Transcript
mboehme edited the summary of this revision. (Show Details)Aug 28 2023, 4:51 AM
mboehme added reviewers: ymandel, xazax.hun.
xazax.hun accepted this revision.Aug 28 2023, 7:26 PM

Thanks! Sometimes I am wondering whether we actually need a full map for PRValues. E.g., once we processed a MaterializeTemporaryExpr, we now have a location for the value, and it feels like we represent the same thing twice, once in ExprToLoc + LocToVal and once in ExprToVal. It is probably not too bad and might be extra work to clean this up.

This revision is now accepted and ready to land.Aug 28 2023, 7:26 PM

Thanks! Sometimes I am wondering whether we actually need a full map for PRValues. E.g., once we processed a MaterializeTemporaryExpr, we now have a location for the value, and it feels like we represent the same thing twice, once in ExprToLoc + LocToVal and once in ExprToVal. It is probably not too bad and might be extra work to clean this up.

Yes, I think it's probably not worth it. (And note that the Exprs in question are different: In the ExprToVal, we map the prvalue expression to a value, whereas in ExprToLoc, we map the MaterializeTemporaryExpr to a location.)

I'd say this is just one example of the more general case when a prvalue is consumed by some other expression. For example, when two prvalue integer operands are consumed by a + BinaryOperator, we could also say that the entries in ExprToVal for the operands are now superfluous and could be removed -- but we still keep them around. They might be superfluous, but there aren't typically enough of them to hurt performance (I think?). And they may be useful for debugging.