On Wed, Jul 21, 2010 at 04:57:10PM +0200, Steven Bosscher wrote:
> On Wed, Jul 21, 2010 at 4:44 PM, Bernd Schmidt <ber...@codesourcery.com> 
> wrote:
> > On 07/21/2010 03:06 PM, Steven Bosscher wrote:
> >> 3. GCC now has better alias analysis than it used to, especially with
> >> the alias-exporting stuff that exports the GIMPLE points-to analysis
> >> results, but also just all the other little things that were
> >> contributed over the last 10 years (little things like tree-ssa :)
> > [...]
> >> It looks like ~9% extra !true_dependence cases are found with cselib,
> >> with is not insignificant:
> >
> > So, if you want to do something useful in this area, try finding out why
> > cselib is still useful despite your point 3 above.  Maybe alias analysis
> > can be improved?
> 
> Yes, this is what I planned to do anyway.
> 
> > If that can't be improved, I think that rather than remove cselib from
> > the scheduler, the question should be: if it's useful, why don't we use
> > it for other schedulers rather than only sched-ebb?
> 
> Well, for one thing: It currently breaks things. See PRs I referenced.

Just because some part of GCC contains a bug doesn't mean we need to nuke
everything related to that bug.  There are bugs in lots of parts of GCC.
There were several bugs fixed in -fsched2-use-superblocks support in the
past year or two, this bug is just something that needs analysing and
fixing.

> We end up not translating the VALUE rtx'en to normal addresses, and
> missing real true dependencies.

I don't think that is a bug, if a VALUE lost all locations, what else
should get_addr return?  I guess the bug is how we are handling such
location-less VALUE.

        Jakub

Reply via email to