Re: Fix PR34916, 35519 Combine (Dataflow merge regression.)

[Andy H <hutchinsonandy at aim dot com>]

Log_links are  awkward - I can easily agree - I did not create them.

But short of a major change to  combine, there is no simple solution.

I looked at just using  DF information - but DF only gives all DEFs - 
not just adjacent DEFs,  so you have to walk instructions to reject 
those with intervening USEs.

I was tempted to leave in duplicates and look for match pairs/triples 
during instruction combine attempts - it looks cheap but of course is 
very expensive!

Check first element might work. The registers are grouped because they 
happen to have been put in DF lists at same time. But there is no 
written constraint that says DF could not re-order the registers in its 
chains - or that the DF chains  have any order. So I did not want to 
propose patch that would break so easily.

The log_links list  being walked is very short - only one element per 
immediately linked instruction. So typical length is perhaps 2 (without 
duplicates). The largest would be for an instruction which has many 
input operands where each is the output of an instructions in same 
block, with no intervening usage.   Maybe a libcall call of some type.  
But still short list!

The bug is problematic as you will have noted from 
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34916 so excuse my 
persistence. :-P

Andy





Richard Guenther wrote:
> On Tue, Mar 18, 2008 at 11:27 PM, Andy H <hutchinsonandy@aim.com> wrote:
>   
> > Please refer to PR35519 which contains a detailed explanation.
> >
> >  *http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35519*
> >
> >  If necessary, I can provide further clarification.
> >
> >  Anything is cheaper than the current bug but  I could not figure out a
> >  cheaper way to solve issue.
> >     
>
> From the comment it seems you could get away just checking the first element
> for the duplicate and not bother to continue walking if that didn't match.
>
> You can add a ENABLE_CHECKING path that verifies this assumption.
>
> Otherwise I think the log-links are a poor data structure ;)
>
> Richard.
>