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

[Richard Biener <richard dot guenther at gmail dot com>]

On Fri, Dec 14, 2012 at 12:16 PM, Michael Zolotukhin
<michael.v.zolotukhin@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.