From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19591 invoked by alias); 18 Nov 2013 11:58:27 -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 19551 invoked by uid 48); 18 Nov 2013 11:58:22 -0000 From: "rguenth at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug c/59159] Need opaque pass-through as optimization barrier Date: Mon, 18 Nov 2013 11:58:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: c X-Bugzilla-Version: 4.9.0 X-Bugzilla-Keywords: X-Bugzilla-Severity: enhancement X-Bugzilla-Who: rguenth 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: bug_status cf_reconfirmed_on everconfirmed 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: 2013-11/txt/msg01630.txt.bz2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59159 Richard Biener changed: What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |NEW Last reconfirmed| |2013-11-18 Ever confirmed|0 |1 --- Comment #3 from Richard Biener --- Well, as you want to guard against propagation across FP state changes I'd rather make that explicit (thus, not make it a generic no-op propagation barrier). Of course thinking about a better representation of FP state in the middle-end would be better as requiring the user to pass every value through such a built-in isn't a nice user interface (yeah, better than making up asms ...). __builtin_protect (...) for a generic name, __builtin_protect_fenv (...) for sth more specific. Both need to be type-generic and only result in no overhead when the argument and return value are registers - consider float f1, f2; foo (&f1, &f2); .. = __builtin_protect (f1); .. = __builtin_protect (f2); which would still cause a redundant load that cannot be optimized until RTL optimization at least. I wonder whether a very early pass splitting functions at FENV clobber points and preventing re-inlining would be a better solution in the end (yeah, making them nested with all the optimization side-effects that causes, which also means _very_ early as unnesting happens more or less during gimplification - or you re-invent unnesting in parts at least).