https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53513
--- Comment #17 from Oleg Endo olegendo at gcc dot gnu.org ---
(In reply to Oleg Endo from comment #14)
The switch is done by 3 (+2 artificial) individual instructions (load -
modify - store). In this case the RA / optimizers figure out that
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53513
--- Comment #14 from Oleg Endo olegendo at gcc dot gnu.org ---
Created attachment 33690
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33690action=edit
a possible patch
This is a simple patch that does sts-lds fpscr mode switching (not
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53513
Oleg Endo olegendo at gcc dot gnu.org changed:
What|Removed |Added
Attachment #33690|0 |1
is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53513
--- Comment #16 from Oleg Endo olegendo at gcc dot gnu.org ---
I've tried a modified example from PR 5360, using floats instead of doubles:
void loop_p (int np, int non0, float coeff[][2048], float tmp1)
{
int j, k;
for (j = non0; j np;
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53513
--- Comment #7 from Oleg Endo olegendo at gcc dot gnu.org ---
(In reply to Rich Felker from comment #6)
On Sun, Mar 16, 2014 at 11:32:21PM +, olegendo at gcc dot gnu.org wrote:
If it's OK for a temporary mode switch to clobber other FPSCR
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53513
chrbr at gcc dot gnu.org changed:
What|Removed |Added
CC||chrbr at gcc dot gnu.org
---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53513
--- Comment #9 from Kazumoto Kojima kkojima at gcc dot gnu.org ---
Although it seems that (1)-(5) in #3 are interesting points, they
are almost optimizations. I guess that programs with frequent FP
mode switchings are simply rare in real world
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53513
--- Comment #10 from Oleg Endo olegendo at gcc dot gnu.org ---
(In reply to Kazumoto Kojima from comment #9)
Although it seems that (1)-(5) in #3 are interesting points, they
are almost optimizations.
Yep. Those are not necessary to get the
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53513
--- Comment #11 from chrbr at gcc dot gnu.org ---
(In reply to Oleg Endo from comment #10)
(In reply to Kazumoto Kojima from comment #9)
Although it seems that (1)-(5) in #3 are interesting points, they
are almost optimizations.
Yep.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53513
--- Comment #12 from Oleg Endo olegendo at gcc dot gnu.org ---
(In reply to chrbr from comment #11)
there were neither followup nor objections to the last version. I'll post
again, the time to cross-check with epiphany or x96.
Epiphany has
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53513
Oleg Endo olegendo at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53513
--- Comment #5 from Oleg Endo olegendo at gcc dot gnu.org ---
(In reply to Oleg Endo from comment #4)
5)
in some cases preserving FPSCR bits across mode changes is not required (if
I'm not mistaken):
double func (float a, float b, double c,
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53513
--- Comment #6 from Rich Felker bugdal at aerifal dot cx ---
On Sun, Mar 16, 2014 at 11:32:21PM +, olegendo at gcc dot gnu.org wrote:
If it's OK for a temporary mode switch to clobber other FPSCR bits (such as in
the PR = single mode above),
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53513
Oleg Endo olegendo at gcc dot gnu.org changed:
What|Removed |Added
CC||bugdal at aerifal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53513
--- Comment #2 from Oleg Endo olegendo at gcc dot gnu.org ---
See also PR 29349.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53513
--- Comment #1 from Oleg Endo olegendo at gcc dot gnu.org 2013-03-10 19:53:56
UTC ---
Some related notes:
According to the public documentation, the 'fschg' insn is only valid when
FPSCR.PR = 0 on all FPU enabled cores (SH2A, SH4, SH4A).
16 matches
Mail list logo
