RE: Fldcw, rounding and optimizations

["Loisel, Sebastien" <loisel at amazon dot com>]

> The latter.  If you need to change rounding modes, and <fenv.h>
> is available, you should use it.  If the compiler doesn't do a
> good job of optimizing the resulting code, then send a bug
> report with the "pessimizes-code" keyword.

I don't think that's the real problem, but maybe that's the gcc way of handling it. <fenv.h> doesn't produce efficient code because bits/fenvinline.h is empty. That file is probably empty because people who would like to put stuff in there have realized that this bug in gcc prevents you from putting stuff in bits/fenvinline.h. I don't see how gcc could inline functions in fenv.h given that there are no inlined definitions to be fetched anywhere.

In addition, and this is not a bug in gcc, but rather a conflict between the spec and the i386 instruction set: fldcw can only set the control word from a memory location. The direct mode isn't available. That means that an invocation of an inline fesetround will typically result in one mov (to set a memory location to the desired word from a register) followed by the appropriate fldcw call. Perhaps this could be optimized with a better gcc, but this is secondary to the problem of creating broken code when the function is inlined at all.

> Personally, I think it is likely that this will be fixed
> some time in the next 20 years.  Maybe sooner if you fix it ;-)

Very encouraging. <conciliatory>I fully appreciate that gcc is a volunteer project, and those who are paid to work on it should follow the priorities of those who pay them. Unfortunately, it is unrealistic for me to dive into this large project to fix it. Simply acquiring the expertise to fix this bug, especially since it looks like it's deep in the innards of gcc, would take an amount of time which my employer (amazon.com) wouldn't be willing to invest, and which I can't invest on my own time, because I'm working on a Ph.D. in math. For these reasons, I fully comprehend that I can not expect to get my pet problems fixed and nobody owes me anything.</conciliatory>

That being said, there's one possible low hanging fruit, but someone would have tell me if I'm right. If indeed my interval code is correct so long as I use fenv.h, it seems to me like the main thing playing out is that gcc is more reticent in reordering code across function calls. Do you think that's the case? If that's the case,

1) Would it make sense to make gcc's optimizer similarly reticent to reorder code across inline asm blocks?
2) Is there a way to do this already? I know you can already specify dependencies of asm blocks on variables and such, and I presume this is used in the optimizer to prevent foul-ups. What's the best way of convincing gcc not to move my asm blocks around?
3) If all else fails, how hard would it be to add some sort of #pragma to prevent reordering code across some critical bit of code?

Thanks,

Sebastien Loisel

-----Original Message-----
From: Fergus Henderson [mailto:fjh@cs.mu.OZ.AU] 
Sent: Thursday, August 14, 2003 8:48 PM
To: Loisel, Sebastien
Cc: Andrew Pinski; gcc@gnu.org; loisel@math.mcgill.ca
Subject: Re: Fldcw, rounding and optimizations


On 14-Aug-2003, Loisel, Sebastien <loisel@amazon.com> wrote:
> Thanks for the information. I see that PR 576 is suspended, what does 
> that mean?

If you click on "Status" on the bugzilla page, <http://gcc.gnu.org/bugzilla/show_bug.cgi?id=576>
then you get an explanation of the different states.
Here's what it says:

 | SUSPENDED 
 | Work on the problem has been postponed. This happens if a timely  | solution is not possible or is not cost-effective at the present time.  | The PR continues to exist, though a solution is not being actively  | sought. [...]

> I guess it won't be fixed in the foreseeable future?

Personally, I think it is likely that this will be fixed some time in the next 20 years.  Maybe sooner if you fix it ;-)

-- 
Fergus Henderson <fjh@cs.mu.oz.au>  |  "I have always known that the pursuit
The University of Melbourne         |  of excellence is a lethal habit"
WWW: <http://www.cs.mu.oz.au/~fjh>  |     -- the last words of T. S. Garp.