This is the mail archive of the gcc-patches@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: [PATCH] -fftz-math: assume that denorms _must_ be flushed to zero optimizations


On Thu, Aug 10, 2017 at 6:39 PM, Pekka Jääskeläinen <pekka@parmance.com> wrote:
> Hi,
>
> The attached patch adds a new switch -fftz-math which makes certain
> optimizations
> assume that "flush to zero" behavior of denormal inputs and outputs is
> not an optimization
> hint, but required behavior for semantical correctness.
>
> The need for this was initiated by HSAIL (BRIG). With HSAIL, flush to
> zero handling is required,
> (not only "allowed") in case an HSAIL instruction is marked with the
> 'ftz' modifier (all HSA Base
> profile instructions are).

This suggests only outputs are flushed to zero?  OTOH documentation
for X * 1 -> X suggests otherwise.  This simplification also suggests to
make FTZ operations explicit instead of adding a flag?  Thus the BRIG
FE would emit FTZ (X) * 1 which we can optimize to FTZ (X), and we
could eventually add a pass optimizing FTZ operations?

> The patch is not complete and likely misses many optimizations.
> However, it is a starting point
> that fixes a few cases brought out by the HSAIL conformance suite. We
> plan to extend this
> as new cases come up.
>
> OK for trunk?

Hmm.  I don't like testing flag_ftz_math too much here.

Are input denormals really required to be flushed to zero or is it enough
to flush outputs to zero?  If the latter then this is more like the modes
not having denormals (and much nicer to optimization, only constant
folding being affected)?

Richard.

> BR,
> Pekka


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