expand and truncate and 387

expand and truncate and 387

[Jan Hubicka]

Hi
I am just looking at expand and truncate patterns. Since i387 holds all data
in same registers and form, they are not required in reg-to-reg cases.
Because they are extremly slow (done by writing to memory and reading back)
it is significant to avoid them (I think people often mix float and double
code just because many programmers use float and all functions are double)
I386.md partially handles this by patterns for each operation with first
extend, second extend and both extended.
This way is bit suboptimal. It makes hard to add new patterns and eliminate
just extensions and just in case only one extension is done.
I am not sure whether eliminating truncate in all cases is corret, but at least
it is good -ffast-math or -mno-ieee-fp candidate.
I think I can halde this by mach operator matching eighter truncate or extend.
Problem is that it still does not solve problem with nested retypes and I should
need to duplicate many patterns (that actually isn't) like important pushing onto
stack case (often used when calling functions) and so on.

Isn't possible to write instruction pattern that match eighter register or
register with truncate/extend expressions? using special predicate or so?


Honza
-- 
                       OK. Lets make a signature file.
+-------------------------------------------------------------------------+
|        Jan Hubicka (Jan Hubi\v{c}ka in TeX) hubicka@freesoft.cz         |
|         Czech free software foundation: http://www.freesoft.cz          |
|AA project - the new way for computer graphics - http://www.ta.jcu.cz/aa |
|  homepage: http://www.paru.cas.cz/~hubicka/ , games koules, Xonix, fast  |
|  fractal zoomer XaoS, index of Czech GNU/Linux/UN*X documentation etc.  | 
+-------------------------------------------------------------------------+

Re: expand and truncate and 387

[Jeffrey A Law]

  In message < 19981027145404.34050@atrey.karlin.mff.cuni.cz >you write:
  > I am just looking at expand and truncate patterns. Since i387 holds all
  > data in same registers and form, they are not required in reg-to-reg cases.
Which expand and truncate patterns?  Please try to be precise, use the
names in the MD file if necessary.

If the values in the registers do not change due to a truncate or extension,
then those patterns should be changed to not emit any real instruction for
those operations.

We need to keep the patterns in the insn chain though.


  > Because they are extremly slow (done by writing to memory and reading back)
  > it is significant to avoid them
So, my question is why are we doing anything for them to begin with.

Can someone else that knows something abou the x86 confirm Jan's assertions?
What is he talking about?  Don't we have to worry about rounding and truncation
when changing modes?

  > I386.md partially handles this by patterns for each operation with first
  > extend, second extend and both extended.
I'm sorry, I have no idea what you are talking about.  

  > I am not sure whether eliminating truncate in all cases is corret, but at
  > least it is good -ffast-math or -mno-ieee-fp candidate.
I disagree.  We don't want to go overboard with either option since all that
will do is make them useless.

Right now, those options control domain checks for things like sqrt and basically
enable some optimizations that are not safe in the presense of a NaN.


jeff

Re: expand and truncate and 387

[Jan Hubicka]

Hi
I've just read more curefully reg-stack sources and I think it solves all my problems :)
It is really piggy and have special cases for all fp instruction (thats why my changes
into patterns caused crashes).
So I should easilly take care for converting expands into real no-ops (possibly
removing them - but this solution will still confuse the scheduler). I also can convert 
the fsincos, because there is special case for sin and cos anyway.
I've also identified the code that emits fstp between condition and jump. It happends
in case both registers in condition dies at the time. If you don't like my fix
in notice_update_cc, I should do another fix, that says, that condition is somewhat
special and can handle cases where two operands are pushed. This should bring some
code duplication between md file and reg-stack and possibly cause a bit worse
scheduling, because there is more time between fstsw and jump. But this is not important.
Advantage is that in really rare cases I should generate fcompp opcode that pops
its operands automatically (but operands must be first two stack register).
So just let me know what solution you like better.
There is no way to fix it w/o breaking one of this two rules IMO.

Honza

Re: expand and truncate and 387

[Stephen L Moshier]

I'm sorry, but I am not able to follow up on this right now.
I am sure law@cygnus realizes there are several different
definitions of "no-op" involved in the misunderstanding.

Re: expand and truncate and 387

[Joern Rennecke]

> Even assuming that there is a subroutine call, how would that allow
> eliminating the convert insn?  According to this scenario the insn has
> just been moved to the other side of the subroutine call.  The value
> to be converted, which used to be in a register, is now in memory, so
> farther from being a no-op than it was before.  The assertion is that
> according to IEEE the conversion is still an operation, it still might
> do something, and it still cannot be deleted.

In order to use the converted value, you have to load it from memory -
which in turn will raise the signal again.
So the only problem arises if the converted value is not used.

Re: expand and truncate and 387

[Richard Henderson]

On Tue, Dec 01, 1998 at 09:13:24AM -0500, Stephen L Moshier wrote:
> Even assuming that there is a subroutine call, how would that allow
> eliminating the convert insn?

(1) The conversion can be combined with the store while flushing
    the register stack.

(2) The conversion can be combined with a load/store pair after
    the subroutine call.

> The assertion is that
> according to IEEE the conversion is still an operation, it still might
> do something, and it still cannot be deleted.

Give me a scenerio, in which the user isn't doing things behind
the compiler's back, in which they can tell the difference.


r~

Re: expand and truncate and 387

[Stephen L Moshier]

>  since all fp regs
> are call-clobbered, there will be no values live in registers.

Even assuming that there is a subroutine call, how would that allow
eliminating the convert insn?  According to this scenario the insn has
just been moved to the other side of the subroutine call.  The value
to be converted, which used to be in a register, is now in memory, so
farther from being a no-op than it was before.  The assertion is that
according to IEEE the conversion is still an operation, it still might
do something, and it still cannot be deleted.

Re: expand and truncate and 387

[Richard Henderson]

On Mon, Nov 30, 1998 at 06:27:23PM -0500, Stephen L Moshier wrote:
> Look at Section 5, "Operations," and Secton 5.3, "Floating-Point Format
> Conversions."

Yes I see.

(1) Extension of normal values is exact, and does nothing since the
    numbers are already in the right form.  Likewise for infinities,
    QNaN, and what would be a denormal in the source precision.

(2) The invalid operation exception for SNaN is signaled when the
    value is loaded with `fld'.  Therefore no additional signaling is
    required when the value is already in a register.

Therefore extension in a register, on x86, is a no-op.


r~

Re: expand and truncate and 387

[Richard Henderson]

On Mon, Nov 30, 1998 at 09:30:41PM -0500, Stephen L Moshier wrote:
> 
>     Therefore no additional signaling is
>     required when the value is already in a register.
> 
> Therefore?  Suppose the value was loaded for some other operation,
> then the user clears the IEEE flags, then calls for a conversion operation
> on the value that is still in the register.  Mustn't there be
> another exception, on the conversion?

I sure _hope_ the user ain't fooling aroung with exception flags
behind my back with asms. 

If they do things properly, they'll be making a function call
to feclearexcept (iso c9x <fenv.h>).  And since all fp regs
are call-clobbered, there will be no values live in registers.


r~

Re: expand and truncate and 387

[Stephen L Moshier]

    Therefore no additional signaling is
    required when the value is already in a register.

Therefore?  Suppose the value was loaded for some other operation,
then the user clears the IEEE flags, then calls for a conversion operation
on the value that is still in the register.  Mustn't there be
another exception, on the conversion?

Re: expand and truncate and 387

[Stephen L Moshier]

>   I havn't checked
> but I'd be very surprised if conversion wasn't in this same category.

Look at Section 5, "Operations," and Secton 5.3, "Floating-Point Format
Conversions."

Re: expand and truncate and 387

[Stephen L Moshier]

I am sorry to have somewhat raised the conversational noise level,
but I'm still very doubtful that you can totally ignore a conversion
operation according to IEEE.

The rebuttal is quite true, that the exception flag "shall be reset
only at the user's request."  Reading on, however, it says the invalid
operation exception is signaled for "any operation on a signaling
NaN."  I think that's ugly, but enough to answer the question.
Anything that is considered an operation might have to do something,
namely it might have to set an exception flag.

Re: expand and truncate and 387

[Stephen L Moshier]

> What?  The accrued exception bits are just that -- accrued.


Here is perhaps a better example, observed in the i386 port.


float f = 1.0e-40;
float g;
double d;

x()
{
  g = f;  /* float -> float   does not set denormal flag  */
  d = f;  /* float -> double  sets denormal flag */
}


Which should it be?

Re: expand and truncate and 387

[Jan Hubicka]

> On Thu, Nov 26, 1998 at 09:51:40AM -0500, Stephen L Moshier wrote:
> > > I believe extensions to be a no-op.
> > 
> > IEEE does not agree.  The reason is that a format conversion is an
> > "operation" which among other things means that the "exception" flags
> > can change as a result.  Suppose you have a value in single precision
> > that is marked with the "inexact" flag.  After extending to double it
> > is no longer inexact, because IEEE 754 para 5.3 says "Conversion to a
> > wider precision is exact."  So to make IEEE happy your no-op would
> > have to clear the inexact flag.
> 
> What?  The accrued exception bits are just that -- accrued.
> Only the user clears them.  Ever.
> 
> Moreover, that "inexact" flag means that some _calculation_
> was inexact.  It says _nothing_ about whether the resulting
> value is denormal or whatnot.
This brings question: is "inexact" flag exact? I don't think so,
since calculations are done in higher precisity. So probably applications
relying on "inexact" flag will not work correctly.

I am now IEEE 754 expert. Can someone tell me, how far is i386.md from
ieee compliance? I387 control word lets specify precisity. Maybe we should
introduce some switch (-mieee-math like on alpha have I believe), that will
set control word to precisity it needs. Extenstions should be done by changing control word
and adding 0 I believe. Maybe it will be more reliable and bring less penalties
than current approach using -ffloat-store.
Once control word handling is implemented using LCM (as was suggested for the
fp->int conversion problem) it should be quite fast (not much since changing
control word is one of the slowest operations.
Will be i386.md ieee 754 compliant then? (or is this step in right direction?)

Can someone point me to source of IEEE 754 specification? Does anyone know
how other compilers behave?

Honza
> 
> 
> r~

-- 
                       OK. Lets make a signature file.
+-------------------------------------------------------------------------+
|        Jan Hubicka (Jan Hubi\v{c}ka in TeX) hubicka@freesoft.cz         |
|         Czech free software foundation: http://www.freesoft.cz          |
|AA project - the new way for computer graphics - http://www.ta.jcu.cz/aa |
|  homepage: http://www.paru.cas.cz/~hubicka/ , games koules, Xonix, fast  |
|  fractal zoomer XaoS, index of Czech GNU/Linux/UN*X documentation etc.  | 
+-------------------------------------------------------------------------+

Re: expand and truncate and 387

[Richard Henderson]

On Thu, Nov 26, 1998 at 09:51:40AM -0500, Stephen L Moshier wrote:
> > I believe extensions to be a no-op.
> 
> IEEE does not agree.  The reason is that a format conversion is an
> "operation" which among other things means that the "exception" flags
> can change as a result.  Suppose you have a value in single precision
> that is marked with the "inexact" flag.  After extending to double it
> is no longer inexact, because IEEE 754 para 5.3 says "Conversion to a
> wider precision is exact."  So to make IEEE happy your no-op would
> have to clear the inexact flag.

What?  The accrued exception bits are just that -- accrued.
Only the user clears them.  Ever.

Moreover, that "inexact" flag means that some _calculation_
was inexact.  It says _nothing_ about whether the resulting
value is denormal or whatnot.


r~

Re: expand and truncate and 387

[Stephen L Moshier]

>   > I386.md will probably never be strictly IEEE 754-ish...
> But that does not mean we should make it less ieee754 complaint.

Usually there is a trick like adding 0.0 that can force the exception
status to be updated.  IEEE awareness such as this would tend to
introduce a significant speed penalty.

Re: expand and truncate and 387

[Jeffrey A Law]

  In message < 19981126170400.14945@atrey.karlin.mff.cuni.cz >you write:
  > So it is probably is wrong.
Quite possibly.

  > Also even in case extension is emmited, it is done using fld. I don't think
  > fld eliminate "inexact" flag. Also I don't know about any way to eliminate 
  > it.
  > I386.md will probably never be strictly IEEE 754-ish...
But that does not mean we should make it less ieee754 complaint.

jeff

Re: expand and truncate and 387

[Jan Hubicka]

> 
> 
> > I believe extensions to be a no-op.
> 
> IEEE does not agree.  The reason is that a format conversion is an
> "operation" which among other things means that the "exception" flags
> can change as a result.  Suppose you have a value in single precision
> that is marked with the "inexact" flag.  After extending to double it
> is no longer inexact, because IEEE 754 para 5.3 says "Conversion to a
> wider precision is exact."  So to make IEEE happy your no-op would
> have to clear the inexact flag.
OK, but from this point of view, i386.md must be incorrect, because it
eliminates certain (not all) extensions for various operations (comparsions,
arithmetic etc.)
So it is probably is wrong.
Also even in case extension is emmited, it is done using fld. I don't think
fld eliminate "inexact" flag. Also I don't know about any way to eliminate it.
I386.md will probably never be strictly IEEE 754-ish...

Honza

-- 
                       OK. Lets make a signature file.
+-------------------------------------------------------------------------+
|        Jan Hubicka (Jan Hubi\v{c}ka in TeX) hubicka@freesoft.cz         |
|         Czech free software foundation: http://www.freesoft.cz          |
|AA project - the new way for computer graphics - http://www.ta.jcu.cz/aa |
|  homepage: http://www.paru.cas.cz/~hubicka/ , games koules, Xonix, fast  |
|  fractal zoomer XaoS, index of Czech GNU/Linux/UN*X documentation etc.  | 
+-------------------------------------------------------------------------+

Re: expand and truncate and 387

[Stephen L Moshier]

> I believe extensions to be a no-op.

IEEE does not agree.  The reason is that a format conversion is an
"operation" which among other things means that the "exception" flags
can change as a result.  Suppose you have a value in single precision
that is marked with the "inexact" flag.  After extending to double it
is no longer inexact, because IEEE 754 para 5.3 says "Conversion to a
wider precision is exact."  So to make IEEE happy your no-op would
have to clear the inexact flag.

Re: expand and truncate and 387

[Richard Henderson]

On Mon, Nov 23, 1998 at 09:59:24AM -0700, Jeffrey A Law wrote:
>   In message < 19981123175442.47382@atrey.karlin.mff.cuni.cz >you write:
>   > We can IMO ignore extensions, since there is no way to do them anyway (it
>   > is not neccesary, since all values are already extended).
> That is *NOT* the impression I've gotten from the other messages on this
> thread.

As I understand it, all values in fp registers exist in the 80-bit
extended double format.  One may twiddle fpcr bits to change where
rounding happens, but that does not affect the overall format.

I believe extensions to be a no-op.


r~

Re: expand and truncate and 387

[Jan Hubicka]

> 
>   In message < Pine.LNX.4.03.9811091738520.15420-100000@moshier.ne.mediaone.net >
> you write:
>   > 
>   > > I don't think the x86 backend worries about rounding and truncation on
>   > > fp->fp conversions.
>   > 
>   > Assuming the usual long-double precision control setting,
>   > converting from lower to higher precision is a no-op.
> Is that something we can safely assume?  I don't think so.
Current implementation of i386.md assumes this. And there is IMO
no way to do another..
> 
> So it seems to me that it really is not safe to ignore extensions & truncations
> on the x86, at least it it is not safe to do by default.

We can IMO ignore extensions, since there is no way to do them anyway (it is
not neccesary, since all values are already extended).
Truncations done by writing to memory should be IMO ignored with some switch,
(math is sitll inexact as it is and truncations costs a lot and don't fix
the problem) but it is not so significant now.

Honza
> 
> jeff

-- 
                       OK. Lets make a signature file.
+-------------------------------------------------------------------------+
|        Jan Hubicka (Jan Hubi\v{c}ka in TeX) hubicka@freesoft.cz         |
|         Czech free software foundation: http://www.freesoft.cz          |
|AA project - the new way for computer graphics - http://www.ta.jcu.cz/aa |
|  homepage: http://www.paru.cas.cz/~hubicka/ , games koules, Xonix, fast  |
|  fractal zoomer XaoS, index of Czech GNU/Linux/UN*X documentation etc.  | 
+-------------------------------------------------------------------------+

Re: expand and truncate and 387

[Jeffrey A Law]

  In message < 19981123175442.47382@atrey.karlin.mff.cuni.cz >you write:
  > We can IMO ignore extensions, since there is no way to do them anyway (it
  > is not neccesary, since all values are already extended).
That is *NOT* the impression I've gotten from the other messages on this
thread.

Until someone else I trust stands up and says yes we can ignore them in a
particular set of cases we will continue to emit them.

jeff

Re: expand and truncate and 387

[Stephen L Moshier]

> Don't the other control settings simply limit the maximum precision available?

The purpose of the precision controls is to invoke strict rounding
rules for each mode.  If you wanted to get mostly the same answers
from x86 as from a real IEEE machine, you would use the precision settings.

> The single precision setting is not recommended, presumably since it
> eliminates double, so there is no point in making conversions work under it.

This sounds like you were hypnotized by Intel spin-doctor propaganda!
On an 8087 or 80287 chip you would not want to use the single
precision setting, no.  The major bugs were fixed in later models.


> This leaves conversion from single (float) to double, and doesn't that work
> the same regardless of whether the control setting is double or long double?

That may be true in one sense, but you might still have to execute an
instruction if you wanted the IEEE flags to be set properly.

Re: expand and truncate and 387

[Stephen L Moshier]

>   > > I don't think the x86 backend worries about rounding and truncation on
>   > > fp->fp conversions.
>   > 
>   > Assuming the usual long-double precision control setting,
>   > converting from lower to higher precision is a no-op.
> Is that something we can safely assume?  I don't think so.

That the setting would not always be long double?  Right, there has
been at least one attempt (at Next) to make the compiler adjust the
settings to match the source program declarations.  Also, if you
wanted the status flags to be "correct" in the IEEE sense, it
might take more than a no-op to accomplish that.

Re: expand and truncate and 387

[N8TM]

In a message dated 11/19/98 3:10:03 PM Pacific Standard Time, law@cygnus.com
writes:

>   > Assuming the usual long-double precision control setting,
>    > converting from lower to higher precision is a no-op.
>  Is that something we can safely assume?  I don't think so.
>  
Don't the other control settings simply limit the maximum precision available?
The single precision setting is not recommended, presumably since it
eliminates double, so there is no point in making conversions work under it.
This leaves conversion from single (float) to double, and doesn't that work
the same regardless of whether the control setting is double or long double?

Re: expand and truncate and 387

[Jeffrey A Law]

  In message < Pine.LNX.4.03.9811091738520.15420-100000@moshier.ne.mediaone.net >
you write:
  > 
  > > I don't think the x86 backend worries about rounding and truncation on
  > > fp->fp conversions.
  > 
  > Assuming the usual long-double precision control setting,
  > converting from lower to higher precision is a no-op.
Is that something we can safely assume?  I don't think so.

  > Converting from higher to lower precision requires the value to
  > be stored out to memory and read back in.  This actually does
  > truncate both the exponent and the significand to the format of the
  > narrower width.
OK.

So it seems to me that it really is not safe to ignore extensions & truncations
on the x86, at least it it is not safe to do by default.

jeff

Re: expand and truncate and 387

[Stephen L Moshier]

> I don't think the x86 backend worries about rounding and truncation on
> fp->fp conversions.

Assuming the usual long-double precision control setting,
converting from lower to higher precision is a no-op.

Converting from higher to lower precision requires the value to
be stored out to memory and read back in.  This actually does
truncate both the exponent and the significand to the format of the
narrower width.

Re: expand and truncate and 387

[Marc Lehmann]

>  > Because they are extremly slow (done by writing to memory and reading back)
>  > it is significant to avoid them
>So, my question is why are we doing anything for them to begin with.
>
>Can someone else that knows something abou the x86 confirm Jan's assertions?
>What is he talking about?  Don't we have to worry about rounding and truncation
>when changing modes?

I don't think the x86 backend worries about rounding and truncation on
fp->fp conversions.

>  > I386.md partially handles this by patterns for each operation with first
>  > extend, second extend and both extended.
>I'm sorry, I have no idea what you are talking about.  

The x86 backend generates a fst/fld combination which costs _alot_ of
cycles, and doesn't seem to serve a purpose (the x86 backend doesn't bother
calculating doubles as doubles and treats them as extended, giving them more
precision)

Since the only side-effect of this insn pair is to generate an exception
my !conjecture! is that either this indeed is their only purpose, or
they are just superflous.

>  > I am not sure whether eliminating truncate in all cases is corret, but at
>  > least it is good -ffast-math or -mno-ieee-fp candidate.
>I disagree.  We don't want to go overboard with either option since all that
>will do is make them useless.
>
>Right now, those options control domain checks for things like sqrt and basically
>enable some optimizations that are not safe in the presense of a NaN.

I think this would pretty much fit that description. But I don't _really_
know what these instructions are supposed to do, they just look like:

mov reg1 -> mem
mov mem -> reg1 (mem dies here)

and the only side effect I can see is possible rounding (Jan?) or exceptions.

      -----==-                                              |
      ----==-- _                                            |
      ---==---(_)__  __ ____  __       Marc Lehmann       +--
      --==---/ / _ \/ // /\ \/ /       pcg@goof.com       |e|
      -=====/_/_//_/\_,_/ /_/\_\                          --+
    The choice of a GNU generation                        |
                                                          |