On Mon, Feb 24, 2014 at 10:02 AM, Richard Biener <richard.guent...@gmail.com> wrote: > On Sun, Feb 23, 2014 at 12:09 PM, Marc Glisse <marc.gli...@inria.fr> wrote: >> Hello, >> >> a natural first step to optimize changes of rounding modes seems to be >> making these 2 functions builtins. I don't know exactly how far >> optimizations will be able to go (the fact that fesetround can fail >> complicates things a lot). What is included here: >> >> 1) fegetround is pure. >> >> 2) Neither function aliases (use or clobber) any memory. I expect this is >> likely not true on all platforms, some probably store the rounding mode in a >> global variable that is accessible through other means (though mixing direct >> accesses with calls to fe*etround seems a questionable style). Any opinion >> or advice here? >> >> Regtested on x86_64-linux-gnu, certainly not for 4.9. > > Hohumm ... before making any of these functions less of a barrier than they > are (at least for loads and stores), shouldn't we think of, and fix, the lack > of > any dependences between FP status word changes and actual arithmetic > instructions? > > In fact, using 'pure' or 'not use/clobber memory' here is exactly walking > on shaking grounds. Simply because we lack of a way to say that > this stmt uses/clobbers the FP state (fegetround would be 'const' when > following your logic in 2)). > > Otherwise, what is it worth optimizing^breaking things even more than > we do now? > > [not that I have an answer for the FP state dependency that I like]
Just to elaborate on the two obvious options: 1) represent all arithmetic with builtins, using an extra explicit FP state argument and set / query that with the FP manipulation / query functions (also with every call) 2) use sth similar to virtual operands - conveniently the vuse/vdef members are present even for unary, binary and ternary assigns (you'd only use the vuse field here). Issues with calls (might consume/clobber FP state) - there the vop fields are already used, so you'd need to add an extra use (easy) and a def (ugh) eventually people wanted to get multiple defs for the simple stmts (assigns and calls) back for stuff like modeling CPU flags explicitely (the overflow flag for example). And FP ISAs now have support for per-stmt rounding mode flags (and element masks for vector instructions). Thus eventually this may be a good reason to support extra (but less efficient to get at / modify?) SSA(!) uses and defs to these stmt kinds. But it needs to be well-designed to not throw away the speedups and simplicity we gained when removing general support for multiple defs. (should be obvious that I lean towards 2) but am not very happy with the consequences for gimple data structures) Richard. > Thanks, > Richard.
