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