From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8709 invoked by alias); 26 Mar 2004 20:15:24 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org Received: (qmail 8675 invoked from network); 26 Mar 2004 20:15:23 -0000 Received: from unknown (HELO nondot.org) (128.174.245.159) by sources.redhat.com with SMTP; 26 Mar 2004 20:15:23 -0000 Received: by nondot.org (Postfix, from userid 501) id 5E56417C2AB; Fri, 26 Mar 2004 15:19:35 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by nondot.org (Postfix) with ESMTP id 5296524C1F2; Fri, 26 Mar 2004 14:19:35 -0600 (CST) Date: Fri, 26 Mar 2004 22:22:00 -0000 From: Chris Lattner To: Richard Guenther Cc: Diego Novillo , Joe Buck , Jeff Law , Subject: Re: -ffast-math and floating point reordering Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-SW-Source: 2004-03/txt/msg01581.txt.bz2 >> Yeah. We sort of discussed adding additional PLUS_EXPR operands and/or >> attributes at last year's summit. But I think that was the extent of >> it. IIRC, there was beer involved, so I doubt anybody was taking notes. > Hmm, this is usually the point where we get the LLVM people tell us what > they are doing here... Okay, first, you must understand that LLVM is under vastly different constraints than GCC is. It makes little sense to have a -ffast-math mode in LLVM. What would happen when you link two .o files with different settings? At best the flag would just be cleared. That said, we don't have an implemented solution to this either at present. My plan is to add a new "fpadd" or "strictadd" instruction or something similar that provides strict FP semantics. The existing LLVM "add" instruction on fp would then be relaxed to allow allow the equivalent of -ffast-math operations. This allows different translation units to be linked together without losing a notion of which operations are strict and which ones are not. This also allows individual translation units to mix different semantics as well. For example, Java has strictfp, and fortran has the parenthesis issue. In a fortran front-end that preserved the appropriate information, this shows how the code generation would differ: x = a + b + c %t1 = add double %a, %b %x = add double %t1, %c x = (a + b) + c %t = fpadd double %a, %b %x = add double %t, %c x = a + (b + c) %t = fpadd double %b, %c %x = add double %t, %a That's the idea. Note again, that this has not been implemented, largely because no one has taken it up (it should be entirely straight-forward). The other advantage of doing this is that we would be able to change code like this: // X + 0 --> X if (I.getOpcode() == Instruction::Add && !I.getType()->isFloatingPoint() && // -0 + +0 = +0, so it's not a noop RHS == Constant::getNullValue(I.getType())) return ReplaceInstUsesWith(I, LHS); With code that looks like this: // X + 0 --> X if (I.getOpcode() == Instruction::Add && RHS == Constant::getNullValue(I.getType())) return ReplaceInstUsesWith(I, LHS); ... leading to cleaner and easier to maintain code. -Chris -- http://llvm.cs.uiuc.edu/ http://www.nondot.org/~sabre/Projects/