FX
2014-09-26 23:25:41 UTC
Hi all,
The attached patch improves our code generation for some of the IEEE_ARITHMETIC functions: some testing functions (is*) and some arithmetic (logb, rint, scalb, âŠ). The interfaces are still present in the module file generated as part of the library (which allows, in particular, for accurate testing of the extent of support we have), but we catch them before emitting the actual function call and emit front-end-generated code instead. This code uses some intrinsics that we didnât use in the front-end so far (some type generic, some not), so I have added them (logb, remainder, rint, signbit).
The patch is nice because it improves the quality of the code generated, eliminating in many cases the need for a function call. It is also a prerequisite to extend our IEEE support to more floating-point types (extended precision and binary128, on some targets including i386/x86_64). Without it, we would have a combinatorial explosion of the number of âhelperâ functions in the library.
Also, Iâm removing symbols from gfortran.map, but no branching/release has occurred since I added them in the first place: it should be all good.
Regtested on x86_64-apple-darwin14. This regresses ieee_2.f90, at -m32 -fno-float-store only, where we seem to trigger a missimplification of __builtin_rint(). Iâll send, just after this one, a mail to gcc to get some help on that, and track the issue separately.
OK to commit?
FX
The attached patch improves our code generation for some of the IEEE_ARITHMETIC functions: some testing functions (is*) and some arithmetic (logb, rint, scalb, âŠ). The interfaces are still present in the module file generated as part of the library (which allows, in particular, for accurate testing of the extent of support we have), but we catch them before emitting the actual function call and emit front-end-generated code instead. This code uses some intrinsics that we didnât use in the front-end so far (some type generic, some not), so I have added them (logb, remainder, rint, signbit).
The patch is nice because it improves the quality of the code generated, eliminating in many cases the need for a function call. It is also a prerequisite to extend our IEEE support to more floating-point types (extended precision and binary128, on some targets including i386/x86_64). Without it, we would have a combinatorial explosion of the number of âhelperâ functions in the library.
Also, Iâm removing symbols from gfortran.map, but no branching/release has occurred since I added them in the first place: it should be all good.
Regtested on x86_64-apple-darwin14. This regresses ieee_2.f90, at -m32 -fno-float-store only, where we seem to trigger a missimplification of __builtin_rint(). Iâll send, just after this one, a mail to gcc to get some help on that, and track the issue separately.
OK to commit?
FX