Re: expand and truncate and 387

[Marc Lehmann <pcg at goof dot com>]

>  > 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                        |
                                                          |