[LLVMdev] Some df_iterator and po_iterator issues
Olaf.Krzikalla at tu-dresden.de
Thu Jul 9 08:26:41 PDT 2009
Chris Lattner schrieb:
>> However if fn replaces childrens of a just processed statement
>> (which happens a lot), the iteration may crash. Looking at
>> df_iterator reveals the reason: the first child of a particular
>> statement is stored too early for this kind of usage. IMHO this
>> could be fixed by delaying the computation of the first child until
>> it's needed (that is in the preincrement operator). The only open
>> question would be: how do we mark the children iterator invalid
>> before its first use.
> This does sound like a useful use-case, but I am uncomfortable with
> making DepthFirstIterator any heavier (by adding "CurrentTopNode" to
> it), is there another way to solve this problem?
I've just brooded over the issue. I think the only way is to move
CurrentTopNode back to VisitStack.
Indeed a very first version (which I have never published here) did
exactly that and used GT::child_end
as a marker, that we are actually the "CurrentTopNode". Of course this
never made it into production as even
GT::child_end might change when the children structure changes. That is
we have no singular value for ChildItTy that could be used as a marker.
The only other place to store this information would be the pointer
itself. And this is the only solution I can think of: we use a
llvm::PointerIntPair<Node*, 1> here instead of Node*. That is, line 74
std::vector<std::pair<llvm::PointerIntPair<Node*, 1> , ChildItTy> >
CurrentTopNode would disappear and I initialze ChildItTy with
GT::child_end (or GT::child_begin, whatever), which however afterwards
will never be read.
Accessing the pointer would become a (very) little bit slower due to the
masking in PointerIntPair.
What do you think about it?
More information about the llvm-dev