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.
