> On 25 Jul 2016, at 11:44, Benjamin Herrenschmidt <b...@kernel.crashing.org> > wrote: > > Hi folks ! > > I could use a bit of help determining if something is quite right in > TCG emulation of FP ops. > > Fabien, Tristan, you submitted a patch back in 2013: > > db72c9f256ae70b30c5d5985234f085df4226c55 "powerpc: correctly handle fpu > exceptions" which effectively makes any of the exceptions generated > for underflow, overflow and inexact fire right away > (helper_raise_exception_err will exit the cpu loop with a setjmp). > > This makes them effectively do the same thing > as float_zero_divide_excp(). > > However I *think* it might not be what we want, according to the > comment in helper_float_check_status() that says > > /* Differred floating-point exception after target FPR update */ > > And according to the architecture definition for those exceptions, > where we indeed want the target FPR updated before we take the > interrupts. > > The code as writte will take the exception before the FPR is updated, > I *think*, or am I missing something here ?
This looks like an oversight. In our tests, we don't read the fpr. > > I think the intent was to return to the translated code so the FPRons > update happen, though we ideally would need to also set some state > so the translated code itself can then check for an exception and > fire it. > > However as you noticed, that doesn't work well either. > > What do you think is the most appropriate implementation here? > > I'm thinking it's almost worth bringing FE0/FE1 into the hflags > so that we know at translation time whether to be precise, imprecise, > or ignore FP exceptions. > > Then we could do something along the lines of: > > - In the helpers, when checking status, set an env flag if an > exception should occur. > > - In all the translate call sites, if FE0/1 is non-0 (at translate > time), generate call to check that flag and shoot the exception > > - Optionally, we could even implement some smarts to defer this to > the end of a TB in imprecise mode. > > An additional note is that if FE0/FE1 are 0, we still in some case > leave an exception behind in cs->exception_index. Now, I *think* > that's ok, it will just be silently dropped at some point, but I am not > 100% certain as that's a part of TCG I'm an not super familiar with > yet. > > What do you guys reckon ? I am missing something here ? I like the second helper suggestion from rth@. That's simple. Tristan.
