This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug rtl-optimization/68664] [6/7 Regression] Speculative sqrt in c-ray main loop causes large slow down
- From: "hubicka at ucw dot cz" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: Mon, 06 Feb 2017 21:14:43 +0000
- Subject: [Bug rtl-optimization/68664] [6/7 Regression] Speculative sqrt in c-ray main loop causes large slow down
- Auto-submitted: auto-generated
- References: <bug-68664-4@http.gcc.gnu.org/bugzilla/>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68664
--- Comment #20 from Jan Hubicka <hubicka at ucw dot cz> ---
> Scheduling should never move very expensive instructions to places they
> are executed more frequently. This patch fixes that, reducing the
> execution time of c-ray by over 40% (I tested on a BE Power7 system).
>
> This introduces a new target hook sched.can_speculate_insn which returns
> whether the scheduler is allowed to speculate a given instruction. The
> rs6000 implementation disallows all divide and square root instructions.
>
>
> PR rtl-optimization/68664
> * target.def (can_speculate_insn): New hook.
> * doc/tm.texi.in (TARGET_SCHED_CAN_SPECULATE_INSN): New hook.
> * doc/tm.texi: Regenerate.
> * sched-rgn.c (can_schedule_ready_p): Use the new hook.
> * config/rs6000/rs6000.c (TARGET_SCHED_CAN_SPECULATE_INSN): New macro.
> (rs6000_sched_can_speculate_insn): New function.
There was also regression on cray for x86-64
https://gcc.opensuse.org/c++bench-czerny/c-ray/
Is it the same issue?
Also with profile feedback perhaps you have enough info to tell that the
speculative path is almost as likely as the original placement.
I wonder if we can provie resonable default by RTX cost...
Honza