On Wed, Jul 21, 2010 at 5:14 PM, Jakub Jelinek <ja...@redhat.com> wrote: >> > 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.
Agreed, and I never suggested that. However, IMHO the situation *may* be different for code that has known bugs, *and* is de facto target specific, *and* receives little testing, *and* gives no measurable benefit in generated code, *and* receives little attention from developers (both bugs I referenced are wrong-code bugs that took very long even to just confirm). I know this opinion is not shared by most people in the GCC community. Bernd's suggestion to enable this in other schedulers is a good idea IMHO because at least that way the code gets much wider test coverage. There are very few people who fix ia64-specific problems, but if this feature is enabled in other schedulers then it's suddenly not ia64-specific anymore. Good. (NB: Alexander Monakov already explained why it's hard for sel-sched to use cselib, see http://gcc.gnu.org/PR43494#c21) But there is a bug to be fixed first. I'll just sit back, enjoy myself, and watch to see if anyone besides me cares enough to have this bug fixed in the not-too-distant future :-) > 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. Note, I already did my best to analyze the bug, or this whole discussion wouldn't have come up in the first place. But I don't fully understand the problem and so I also don't know how to fix it. >> 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. Well, I don't understand how we can end up with a VALUE in sched-deps that has lost all its locations in the first place. The VALUE without locations is in a MEM of the insn that sched_analyze_insn is working on, so there should be a location for this VALUE (i.e. in the insn that's being analyzed). Ciao! Steven