[tree-ssa]: PRE updates and note on bug

[Daniel Berlin]

On Tuesday, July 22, 2003, at 1:57 PM, Andrew MacLeod wrote:

> On Tue, 2003-07-22 at 13:37, Daniel Berlin wrote:
>>
>
>>> but....  are you sure you are looking at the right thing?
>>>
>
>>>
>>> out_of_ssa doesnt use the reverse iterators, but it does use the
>>> FOR_EACH_STMT_IN_REVERSE macro because its processes things 
>>> backwards,
>>> and its not having any problems. If things were screwed up by DCE,
>>> something would get the wrong live range, or get missed, and I would
>>> expect something to break later on.
>>
>> As I said, it could be the reverse iterators.
>> If the end of the bb is an empty statement, bsi = bsi_last (bb);
>> bsi_prev (bsi), doesn't work.
>> If it should, then the reverse iterators are broken.
>
> then thats the problem...
>
>> If the end of the bb shouldn't be an empty statement, then the bb ends
>> aren't being updated.
>>
> And thats not the problem.
>
>>>
>>> If the end of block pointer is actually set wrong, the forward
>>> iterators
>>> would be missing stmts or something I would think.
>>>
>> Nope. They skip the empty statements, so they don't see the problem.
>>
>
> And bsi_prev is implemented using bsi_next from the start of the block
> to find the previous stmt, so the same limitations would be 
> encountered.
> Its an interaction between bsi_last and bsi_prev

Figures.

>
>> 1. The patch I pasted inserts the check when *DCE* runs, which is the
>> first thing that runs.
>> Not when PRE would run.
>> It has nothing to do with PRE at all.
>> You will see the problem any time you use reverse iterators.
>> which is #2
>> 2. Nothing else uses reverse iterators.
>>
>
> sooooooo.. wouldnt the natural conclusion be to look at the iterator?
>

Not if you are visiting your parents at the same time you are trying to 
solve the problem.

> Like I said, Im contemplating ditching bsi_prev anyway... no-one uses 
> it
> and its horribly inefficient.
>
Kay.

> Besides, since its the iterator thats broken, stop using it to check
> your stmt count and move on. It shouldnt be affecting you since you 
> dont
> use it for any real work. Consider it removed, I'll take it out in my
> round after next of changes. And/or fix it when I get a chance.
>


We probably need to revert the tree-cfg change then i made last week, 
since that is likely the fault of the iterator as well.
I'll bootstrap and check
>