[Bug debug/54402] [4.8 Regression] var-tracking does not scale

jakub at gcc dot gnu.org gcc-bugzilla@gcc.gnu.org
Wed Dec 12 22:10:00 GMT 2012


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54402

--- Comment #21 from Jakub Jelinek <jakub at gcc dot gnu.org> 2012-12-12 22:09:59 UTC ---
Created attachment 28941
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28941
sparc hack

I think on SPARC that is partly the fault of the sparc.md part of
http://gcc.gnu.org/ml/gcc-patches/2011-06/msg01423.html
The old insn pattern was much closer to what the insn actually does, so now
neither cselib nor var-tracking has any clue on what the insn is doing, doesn't
consider it as a a fp_setter among other things.
If the looked the way it did before, and even better also described what it
does with the o0-o5 registers too, then no hacks like var-tracking.c
HAVE_window_save code would be needed, cselib would just understand it.

That said, another alternative is another hack when we already have some, treat
window_save insn as fp_setter_insn (or could derive it from some of the CFA
flags).  Still I think that earlier when discussing UNSPEC_VOLATILE we were
talking that UNSPEC_VOLATILE is mainly about being a scheduling barrier and
that it shouldn't e.g. modify registers that it doesn't say that are modified.

Haven't measured how much this patch improves the compile time, but not enough
in a x86_64-linux -> sparc-solaris cross.  So I'm going to attach other patches
too, to be tried separately and/or together with this.



More information about the Gcc-bugs mailing list