[LLVMdev] Some df_iterator and po_iterator issues

[Olaf Krzikalla]

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 
would read:

std::vector<std::pair<llvm::PointerIntPair<Node*, 1> , ChildItTy> > 
VisitStack;

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?

Best
Olaf Krzikalla