add fenv cache to task struct

[simonbyrne]

Fixes #51277. I know @vchuravy is skeptical, but I wanted to try it out.

To give some examples:

julia> t = Base.Rounding.setrounding_raw(Float64, Base.Rounding.to_fenv(RoundDown)) do
           Task(() -> println(rounding(Float64)))
       end
Task (runnable) @0x000000010dff04c0

julia> rounding(Float64)
RoundingMode{:Nearest}()

julia> wait(schedule(t))
RoundingMode{:Down}() # currently gives RoundingMode{:Nearest}()

julia> rounding(Float64)
RoundingMode{:Nearest}()

julia> Base.Rounding.setrounding_raw(Float64, Base.Rounding.to_fenv(RoundDown)) do
           Threads.@threads :static for i = 1:Threads.nthreads()
               println(Threads.threadid() =>  rounding(Float64))
           end
       end
1 => RoundingMode{:Down}()
2 => RoundingMode{:Down}() # currently gives RoundingMode{:Nearest}()
4 => RoundingMode{:Down}() # currently gives RoundingMode{:Nearest}()
3 => RoundingMode{:Down}() # currently gives RoundingMode{:Nearest}()

[vtjnash]

I think this should work

[vtjnash]

This should come before the task switch, as some task switch implementations will clobber it

[simonbyrne]

Where specifically should it go?

[vtjnash]

Or rather, it looks like the fesetenv is the one that needed to move

[simonbyrne]

Where should it go?

[simonbyrne]

Feel free to push to this branch

[vtjnash]

Already done. I don't know about the propagating behavior though. I think we might want to start every task with a call to set fesetenv(FE_DFL_ENV)?

[vchuravy]

I am still not convinced that this is a good thing to do. We have not yet specified what fenv means on the language level and if we want to support it in these cases. Echoing #51277 (comment)

Doesn't longjmp/setjmp save fenv? E.g. why do we have to do manually?

[vtjnash]

I don't think so. That is a very significant problem for anyone using this API, but I don't think it means it is wrong to do this PR (e.g. https://github.com/lattera/glibc/blob/master/sysdeps/x86_64/jmpbuf-offsets.h and https://github.com/lattera/glibc/blob/master/sysdeps/x86_64/__longjmp.S have no space to be capable of storing it)

[vchuravy]

Two notes:

The C standard defines fenv as thread-local, I do agree that it would make sense to define it as a scoped value (as implemented here) and a task would copy the fence from its parent.

I do still maintain that doing so is preemptive without adding language level support for strictfp and constrained floating point ops as defined by LLVM for this purpose.

Also see https://internals.rust-lang.org/t/equivalent-of-pragma-stdc-fenv-access-on/14934

I am okay with merging this partial support under the understanding that there is a declaration of intent to actually develop the full language semantics and that setting or accessing fenv remains UB.

Because right now messing with fenv and then entering the compiler that does some constant evaluation sounds like a recipe for causing hard to track down bugs.