This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Adding Rounding Mode to Operations Opcodes in Gimple and RTL


On Fri, 14 Dec 2012, Michael Zolotukhin wrote:

I found quite an old bug PR34768 and was thinking of doing what was
suggested there.

Wrong bug number? 34678 probably.


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.

Dealing with rounding modes sounds like a great (and hard) thing, much needed by some users: here we wrap all operations with asm("":"+m"(x)) currently ("+mx" for sse, for some reason "+g" didn't seem to impact optimization last time I checked), because -frounding-math doesn't really work (simplify_const_unary_operation does constant propagation on sqrt, some rtl pass notices common sub-expressions and merges them despite a change of rounding mode in between, etc).


One thing that seems to make sense but would be way too large a change is to actually represent operations roughly the way they work in C and on x86: + is a function that takes 3 arguments (the 3rd is a global (TLS) variable describing the rounding mode) and has 2 outputs (already an issue in itself): the sum, and a tmp that is just used for exception_flags |= tmp. In some cases, you would know the rounding mode, but in the usual case where you don't, you could still know that (with some flags) a*b+c could be optimized to fma(a,b,c) if and only if * and + have compatible rounding modes (i.e. the same, or one has "don't care"). Things like common sub-expression optimization would work just fine: external function calls or asm might change the global variable, and without them the global variable remains the same and since the operator+ is const...

I don't know how modeling the rounding mode flag as a global variable would work with the mode_switching pass.

Not a realistic suggestion though :-(

Take this message as encouragement to improve this in any way you can :-)

--
Marc Glisse


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]