On Fri, Dec 14, 2012 at 12:16 PM, Michael Zolotukhin <michael.v.zolotuk...@gmail.com> wrote: > Hi, > I found quite an old bug PR34768 and was thinking of doing what was > suggested there. > Particularly, I was wondering about adding new subcodes to gimple and > rtl for describing operations with rounding. > > Currently, I think the problem could be tackled in the following way: > In gimple we'll need to add a pass that would a) find regions with > constant, compile-time known rounding mode, b) replace operations with > subcodes like plus/minus/div/etc. with the corresponding operations > with rounding (plus_ru, plus_rd etc.), c) remove fesetround calls if > the region doesn't contain instructions that could depend on rounding > mode. > In RTL we'll need to support the instructions with rounding mode, and > also we'll need to be able to somehow emit such instructions. > Probably, we'll need a reverse transformation to insert fesetround > calls around the regions with instructions with rounding - that could > be done by mode_switching pass. > > If this approach looks reasonable to you, then there are more questions: > 1) What is the best way to represent operations with rounding in > Gimple and RTL? Should we add plus_round and add an attribute to > describe rounding mode, or we should add opcodes for different > rounding modes (plus_round_up, plus_round_down, etc.) - of course, > that should be done for all opcodes that are affected by rounding, not > only plus-opcode. > 2) What's the best place to insert the new passes? > > Any other input is more than welcome on this.
Exposing known rounding modes as new operation codes may sound like a good idea (well, I went a similar way with trying to make operations with undefined overflow explicit ... but the fallout was quite large even though there is only one kind of undefined overflow and not many operation codes that are affected ... so the work stalled - see no-undefined-overflow branch). But don't under-estimate the fallout - both in wrong-code and missed-optimizations. You'd definitely want to keep 'unknown rounding mode' operation codes (where I'd suggest to make the existing ones match that). Not sure if we want to start allocating sub-spaces of codes to a group to allow flag-like composition (say, PLUS_EXPR gets 0x10 and the lower nibble specifies the rounding mode). It looks more appealing for the rounding mode case (more cases) than for the binary (un-)defined overflow case. You'd want to expose the rounding mode libc functions as builtins to be able to detect them. That's good anyway and can be done independently (they currently act as memory optimization barrier which avoids most of the issues with -frounding-math support). Insertion of rounding mode changes has to be done after 2nd scheduling (and you probably want to have even 1st scheduling optimize the schedule for rounding mode changes ...). Machine-reorg is one natural place to do it (or where we currently insert vzeroupper). Similar to the FP rounding mode mess is handling of undefined overflow, also a similar mess but with a different proposed solution is that of -ftrapv support (and general overflow detection) - there is a bugreport which contains quite detailed analysis and suggestion from Joseph about this. Unless you really need the FP rounding mode problem solved I suggest to look at either "simpler" issues first ;) Thanks, Richard. > -- > --- > Best regards, > Michael V. Zolotukhin, > Software Engineer > Intel Corporation.
