This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Revisiting the use of cselib in alias.c for scheduling
On Wed, Jul 21, 2010 at 5:14 PM, Jakub Jelinek <jakub@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