GCC 3.5 Status (2004-08-29)

[Daniel Berlin]

On Sun, 29 Aug 2004, Mark Mitchell wrote:

> Andrew Pinski wrote:
>
>> 
>> On Aug 29, 2004, at 4:17 PM, Mark Mitchell wrote:
>> 
>>> * Aliasing improvements for structure fields [Berlin]
>> 
>> 
>> Actually without this, we will produce wrong code so I think this one
>> should be rethought about and not delaying it until 3.6.
>
> I think you are talking about something different.
>
> In particular, this is work that Dan said he could not complete for several 
> months.  I fail to  believe that PR 15262 cannot be fixed without adding lots 
> of new optimization infrastructure.

This is correct (the time estimate).
Being realistic, without help, it will be several months before it can be 
complete (IE when it's not causing regressions and all latent bugs are 
fixed).Of course, if it  doesn't expose any latent bugs, causes no 
testsuite failures, a good design for how to integrate the information 
is quickly agreed upon, and others were to help out with the integrating 
(there are a few pieces that should be able to be parallelized once a 
design is agreed upon), the time could be significantly shortened.

A lot of that  time is going to be spent in the  infrastructure necessary 
to make this useful, which encompasses a lot of 
the low hanging fruit by definition (simply saying that a store to a.b 
doesn't kill the entire value of a).
In fact, this is actually where most of these months is going to be spent 
(and fixing latent bugs/problems that pop up as a result).

Actually writing something that produces the alias information we want 
(knowing whether p->a and p->b alias, knowing whether x[0] and x[1] 
alias), and  making sure it gives correct 
results for corner cases, is what i saw as the easy part, at least for me.
This is, in fact, done, bootstrapping, and passes all it's internal 
checking during bootstrap.  I've tested it on some wonky cases, and it 
produces what appear to be correct results.
I can post it tommorrow if people want to see it.
There are improvements that could be made to the results, of 
course, and TODO's, but none that were so important as the basic 
information.

Using the information, of course, is the part that is going to require the 
architectural changes, design work, etc.

I just sent some email to Diego and RTH this morning to see if they had 
any thoughts about what to do here, along with a somewhat simplistic idea 
of how to solve the "a.b vs a.c" issue.

I'll note that a design is agreed upon for the "make stores 
to a.b not kill a.c" issue, if others were to help implement it, we could 
probably tackle it before 3.5 (IE in the next month), and i would happily 
do the rest of the work alone (if need be) for "p->a vs p->b, a[0] vs 
a[1]", etc

--Dan