https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53513
--- Comment #17 from Oleg Endo ---
(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 there's
> no need to sto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53513
--- Comment #16 from Oleg Endo ---
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; j++)
for (k = 0; k < j; k
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53513
Oleg Endo changed:
What|Removed |Added
Attachment #33690|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53513
--- Comment #14 from Oleg Endo ---
Created attachment 33690
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33690&action=edit
a possible patch
This is a simple patch that does sts-lds fpscr mode switching (not fully
tested).
With the patch
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53513
--- Comment #12 from Oleg Endo ---
(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 some additional mode sw
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.
>
> Ye
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53513
--- Comment #10 from Oleg Endo ---
(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 functionality (of not usin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53513
--- Comment #9 from Kazumoto Kojima ---
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 and would be a bit
special or
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
--- Co
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53513
--- Comment #7 from Oleg Endo ---
(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 bits (such as
> > in
> >
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53513
--- Comment #6 from Rich Felker ---
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), it should also be OK t
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53513
--- Comment #5 from Oleg Endo ---
(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, double d)
> {
> #prag
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53513
Oleg Endo changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53513
Oleg Endo changed:
What|Removed |Added
CC||bugdal at aerifal dot cx
--- Comment #3 from
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53513
--- Comment #2 from Oleg Endo ---
See also PR 29349.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53513
--- Comment #1 from Oleg Endo 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).
On SH4 and SH4A the 'frc
16 matches
Mail list logo
