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. Those are not necessary to get the functionality (of not using > __fpscr_values). > > > I guess that programs with frequent FP > > mode switchings are simply rare in real world and would be a bit > > special or even pathological in the first place. > > I like the idea of mode switching without __fpscr_values even if it > > requires more instructions on SH4. Now SH4 is a fairy old core and > > is not for heavy FP computations anyway. I think that it won't impact > > the real working set. > > It looks to me that Christian's patch is the way to go. > > Yep. However, when the patch was proposed there were some objections > regarding the modifications in lcm.c (if I'm not mistaken). We could try > again. there were neither followup nor objections to the last version. I'll post again, the time to cross-check with epiphany or x96. > > The reason why I brought up (1)-(5) in #3 was that if one of them is > eventually implemented (e.g. reorder calculation insns) the changes to lcm.c > might not be required and could be avoided. Depending on the implementation > of such optimization, the mode switch information might have to be > obtained/maintained in a different way. However, I at the moment I have no > concrete ideas/plans. If Christian's patch is accepted, that's cool, too. Implementing in LCM can also be a base to expose the architectural mode flipping extension with other ports (MMX was suggested I think)
