This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] Add a barrier in the double fma implementation


On Wed, 15 Feb 2012, Roland McGrath wrote:

> I try to avoid knowing anything about floating-point.  But it seems like
> this would be an issue for applications too.  I wonder if fetestexcept et
> al shouldn't have barriers themselves?  I guess the public calls are actual
> functions, so they are all implicit barriers--but does that hold under
> static linking plus massive link-time interprocedural optimization (which
> could come along some day even if it's not all here yet).

In general there are a range of GCC bugs around exceptions and rounding 
modes.  But ultimately if those are fixed I'd expect the following to be 
the case:

* Any function call might end up calling one of the fe* functions 
indirectly and so the compiler must allow for it doing so, unless it can 
see the body of the function called.

* asms accessing/clobbering the floating-point exceptions and rounding 
modes must be treated similarly to function calls.

On platforms where a register name is defined by GCC for asms to say that 
they refer to floating-point state, it's probably reasonable to treat it 
as a bug in any preexisting asms that they fail to declare this.  On 
platforms with such state but no register name, the most compatible 
approach would be to say that all asms implicitly use this state - but 
since most asms probably *don't*, things may end up more optimal if asms 
using that state are required to change to declare what they are doing.  
(At that point, relevant asms in glibc would need to change conditional on 
whether GCC is a version supporting the relevant register name.  It's 
hardly uncommon for glibc to need to change to be built with newer GCC 
versions.  And of course the register names could be added to GCC without 
the real support for floating-point state, so allowing asms to be updated 
in advance of the changes being needed.)

Regarding this patch: it does the same thing as is done elsewhere in 
related code, so I'd say it should go in (with a copyright dates update) 
even if later there might be a better fix.

-- 
Joseph S. Myers
joseph@codesourcery.com


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]