Not a bug, but a big trouble indeed
Richard Earnshaw
rearnsha@arm.com
Tue Feb 3 02:45:00 GMT 1998
> In message < 34D62CF0.3B1104FC@shellus.com >you write:
> > > > >Maybe the way to go would be some kind of way to specify in the asm
> > > > >that it alters *state of the entire machine* in an unknown way.
> > > >
> > > > But you don't want to change the entire machine, but only relatively
> > > > small pieces ot it. In this case, FP operations on either side of
> > > > the asm may not be combined, but no register state is changed, and
> > > > int operations may continue to be combined.
> > > My thought was make it work, then tune it later :-) Certainly wiping
> > > just FP values from the hash table would work better :-)
> >
> > Actually, you may not necessarily want to wipe out fp values from your hash
> > table. You may want to add a specifier to the key which detailed what was
> > known about the fp state of the machine during the computation. I say this
> > because, were such a capability available in gcc, I know I would have used it
> > like so:
> Well, I'd approach this in the same manner -- first get something that works,
> then iterate on it until it's not worth improving anymore.
>
> And, yes, we'd have to assume that calls clobber the rounding mode... Hmmmm...
Not necessarily. In the ARM's floating point implementation, the rounding
mode is part of the instruction.
That also means you can't change the rounding mode by calling a function
(as the original code in this thread was trying to do).
More information about the Gcc-bugs
mailing list