From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1323 invoked by alias); 17 Mar 2014 15:18:34 -0000 Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org Received: (qmail 1277 invoked by uid 48); 17 Mar 2014 15:18:30 -0000 From: "chrbr at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug target/53513] SH Target: Add support for fschg and fpchg insns Date: Mon, 17 Mar 2014 15:18:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: target X-Bugzilla-Version: 4.8.0 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: chrbr at gcc dot gnu.org X-Bugzilla-Status: NEW X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-SW-Source: 2014-03/txt/msg01444.txt.bz2 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)