This is the mail archive of the 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: -fstrict-fp-semantics (was Re: numerical instability and estimate-probability)

> > > Can we adopt an option, say -fstrict-fp-semantics, that means that fp
> > > results are not changed *one bit* by any optimization?
> > I am not quite sure how to reach it w/o important penalty in the perofrmance.
> I presume that there is so little time in gcc spent in fp that the
> performance penalty wouldn't matter.
Agreed - but gcc only solution is to put in that volatile keyword.
It brings stablity I need.  I tought you are shooting for sollution
for numeric programmers.
> > Even if we jump into 80bit spills (I was trying to implement it, but never got
> > it working, unfortuantely), we still need to disable any load/store propagation
> > that may elliminate the truncate.
> > This is quite nasty.
> I don't believe that this is necessary.  If you have an expression that's lifted
> above a loop, then lift it as an extended.
> >  It may be reached by making every FP memory reference
> > volatile, but that sounds crazy too.
> This is definitely not necessary.
Imagine followin code.


where a is an global variable and t is local.  If you avoid the redundant
load/store pair, you avoid the truncating and t will differ.

The loop optimization basically deals with such a sequence.

> > Also it won't solve the problem with bootstrap, as stage1 compiler may
> > be non-gcc one and still may produce different result :(
> It adds another iteration, which is unpleasant.
> Brad

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