Quoting Jan Hubicka <[EMAIL PROTECTED]>: > If you make FPCTR/MXCSR real registers, you will need to add use to all > the arithmetic and move pattern that would consume quite some memory and > confuse optimizers. I think you can get better around simply using volatile > unspecs inserted by LCM pass (this would limit scheduling, but I don't > think it is that big deal)
Ouch... I wrongly assumed that rouding bits affect only (int)->(float) patterns - thanks for clearing this to me! (Perhaps adding a "nearest" i387_cw attribute to arithmetic/move patterns could be used to switch back to default rounding?) > > Unfortunatelly, in first testcase, fldcw is not moved out of the loop, > > because > > fix_trunc<mode>_i387_2 is splitted after gcse-after-reload pass (Is this > > intentional for gcse-after-reload pass?) > > It is intentional for reload pass. I guess gcse might be run after > splitting, but not sure what the interferences are. I have added split_all_insns call before gcse_after_reload_main in passes.c. To my suprise, it didn't break anything, but it also didn't get fldcw out of the loop. Uros.
