Re: GCC floating point usage

[Mark Mitchell <mark at codesourcery dot com>]

> Zack's spec:
> > The intent is that it's a guarantee that floating-point instructions
> > will not be *executed* by a function compiled under -mno-implicit-fp,
> > unless that function either (a) uses floating point numbers, or (b)
> > uses a small, documented set of primitives where the implementation
> > has to use floating point even if the caller doesn't (such as
> > setjmp/longjmp).
> I think that Mike had yet another spec in mind, in which using certain
> primitives (like setjmp, EH, etc.) in this situation is user error and
> causes undefined behaviour, but I'm not sure.
I think that Zack and Mike mean the same thing, and that I was close,
but slightly off.  Obviously, it doesn't matter whether the compiler
generates FP ops if they can never be executed.  (In fact, it doesn't
really matter if it stuffs totally random bytes into the text
section if you can't ever get there.)

So, perhaps, amend my spec to say "will not generate floating-point
instructions that can ever be executed by a program that does not
call setjmp or throw an exception."

> (a) Does this affect codegen when the new feature is not enabled?
>     Zack's patch does, and it shouldn't.
I certainly agree that people not using the flag should see no change.

Why does Zack's patch do that, given his caveat that the sense of the
flag would be reversed so that the flag is off by default?

> The obvious way to do this is to create an entry in struct function,
> set by the middle-end, "current_function_uses_float", and then use that
> to determine whether the stfd/lfd/fmr instructions are available in
> the backend.
I guess that would work; you would test the flag in the predicate for
the instruction.  That will, however, be a more invasive patch (you
have to try to find all the places in the middle end where floats might
be used).

--
Mark Mitchell                mark@codesourcery.com
CodeSourcery, LLC            http://www.codesourcery.com