On 4/24/23 07:51, Andrew MacLeod wrote:
Its not a real cache.. its merely a statement shortcut in dependency
analysis to avoid re-parsing statements every time we look at them for
dependency analysis
It is not suppose to be used for anything other than dependency
checking. ie, if an SSA_NAME changes, we can check if it matches
either of the 2 "cached" names on this DEF, and if so, we know this name
is stale. we are never actually suppose to use the dependency cached
values to drive anything, merely respond to the question if either
matches a given name. So it doesnt matter if the name here has been freed
OK. I'll take your word for it. Note that a free'd SSA_NAME may have
an empty TREE_TYPE or an unexpected TREE_CHAIN field IIRC. So you have
to be a bit careful if you're going to allow them.
We never re-use SSA names from within the pass releasing it. But if
the ranger cache
persists across passes this could be a problem. See
This particular valueswould never persist beyond a current pass.. its
just the dependency chains and they would get rebuilt every time because
the IL has changed.
Good. THat would limit the concerns significantly. I don't think we
recycle names within a pass anymore (we used to within DOM due to the
way threading worked eons ago, but we no longer take things out of SSA
form to handle the CFG/SSA graph updates. One could even argue we don't
need to maintain the freelist and recycle names anymore.
Jeff
