|
From: Jean-Marc V. <jea...@us...> - 2006-03-02 04:59:09
|
Hi, If I'm not mistaken, the current Valgrind behaviour for arithmetic operations operations on undefined values is to not generate an error and simply mark the result at undefined. While this is probably the right thing to do for some operations (e.g. bitwise OR), I believe there are cases where an error should actually be reported because some arithmetic instructions can actually cause exceptions. There's a list of some of these instructions and my current thoughts on them. DIV/IDIV First obvious case: if the denominator is undefined, then it can be zero, which would cause an exception. It is therefore useful to produce an error in this case, unless the exception mask is set. A less obvious case is if the numerator is undefined and if (and only if) the denominator is equal to -1. In this case, an exception could also be generated if the undefined numerator end up being 0x80000000. So, I think an error should also be reported for "undefined / -1" FDIV Same as for DIV/IDIV, I think it should report an error if the demoninator is undefined. FIST/FISTP (Store Integer) Storing (converting) an uninitialized float value to int may cause an exception if the value is +-inf, NaN or too large for the int size. So, operating on an undefined value should cause an error I think. By default, the exception seems to be masked, but I think reporting an error could help in cases where the int ends up as an array index. General float arithmetic I'm not sure about that one, but since any float operation (add,sub,mul,div,load,store,sqrt,...) can cause an exception if one of the operands is NaN, inf or denormalised, it *may* be a good idea to generate an error if any float data is used while undefined. Or maybe this could be left as an option, I'm not sure. Even if masked, these instructions tend to slow down the program when you have NaNs and infs. SSE I don't think SSE arithmetic instructions can generate any exception, so it's probably safer not to report errors on SSE arithmetic operations. On a slightly related note, I think it would be useful to include an options to report warnings whenever there are floating point operations on denormalised values. While it is legal, there are many CPUs (especially the P4) that perform *very* slowly on denormalised values and there is currently no tool that helps detecting that. The only way one notices the problem is when an applications starts becoming really, really slow for no apparent reason. This is what happened to me with Speex, when the decoder was suddenly 100x slower than normal. The same could actually be done with NaNs, which are sometimes hard to track down when doing numerical work. Would be nice to be able to know where the first NaN got created. Hope these comments are welcome. Please CC any response/comments to me, since I'm not subscribed. Thanks, Jean-Marc |
|
From: Tom H. <to...@co...> - 2006-03-02 10:14:09
|
In message <114...@th...>
Jean-Marc Valin <jea...@us...> wrote:
> On a slightly related note, I think it would be useful to include an
> options to report warnings whenever there are floating point operations
> on denormalised values. While it is legal, there are many CPUs
> (especially the P4) that perform *very* slowly on denormalised values
> and there is currently no tool that helps detecting that. The only way
> one notices the problem is when an applications starts becoming really,
> really slow for no apparent reason. This is what happened to me with
> Speex, when the decoder was suddenly 100x slower than normal.
>
> The same could actually be done with NaNs, which are sometimes hard to
> track down when doing numerical work. Would be nice to be able to know
> where the first NaN got created.
Might this sort of thing not be better done with a new tool
though - perhaps a floatcheck tool or something?
In fact I think the projects page on the web site has some
suggestions along those lines.
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Julian S. <js...@ac...> - 2006-03-02 10:31:06
|
> DIV/IDIV > First obvious case: if the denominator is undefined, then it can be > zero, which would cause an exception. I agree. Memcheck could do better here and it would be easy to do so. > A less obvious case is if the numerator is undefined and if (and only > if) the denominator is equal to -1. In this case, an exception could > also be generated if the undefined numerator end up being 0x80000000. Could do, but is pretty obscure and would give some performance overhead. > FDIV > Same as for DIV/IDIV, I think it should report an error if the > demoninator is undefined. With IEEE default exceptions set, which is the only FP exception setting V supports, dividing by zero gives +Inf/-Inf, but no exception. > FIST/FISTP (Store Integer) > Storing (converting) an uninitialized float value to int may cause an > exception if the value is +-inf, NaN or too large for the int size. My understanding on x86/amd64 is that the result is a value the docs call 'integer indefinite', which is 0x8000...0000. And on ppc the same happens except you get either 0x800... or 0x7FF.... > I'm not sure about that one, but since any float operation > (add,sub,mul,div,load,store,sqrt,...) can cause an exception if one of > the operands is NaN, inf or denormalised, Well, as per above, V only supports IEEE exceptions masked. > SSE > I don't think SSE arithmetic instructions can generate any exception, so > it's probably safer not to report errors on SSE arithmetic operations. I believe SSE FP arithmetic can generate exceptions. If it couldn't, SSE would be useless as a way of doing IEEE compliant FP arithmetic. > On a slightly related note, I think it would be useful to include an > options to report warnings whenever there are floating point operations > on denormalised values. While it is legal, there are many CPUs > (especially the P4) that perform *very* slowly on denormalised values > and there is currently no tool that helps detecting that. The only way > one notices the problem is when an applications starts becoming really, > really slow for no apparent reason. This is what happened to me with > Speex, when the decoder was suddenly 100x slower than normal. Yeh, I've heard of the P4 denormalised value performance disaster phenomenon before now. Detecting this would fall more into the area of a profiling tool though. It wouldn't be hard to do. J |
|
From: Jean-Marc V.
|
Le jeudi 02 mars 2006 =E0 10:30 +0000, Julian Seward a =E9crit : > > DIV/IDIV > > First obvious case: if the denominator is undefined, then it can be > > zero, which would cause an exception. >=20 > I agree. Memcheck could do better here and it would be easy to do so. Good. > > A less obvious case is if the numerator is undefined and if (and only=20 > > if) the denominator is equal to -1. In this case, an exception could=20 > > also be generated if the undefined numerator end up being 0x80000000. >=20 > Could do, but is pretty obscure and would give some performance overhead. Would it? The check only needs to happen if the numerator is undefined in the first place. It's just that the error isn't reported if denominator!=3D0. > > FDIV > > Same as for DIV/IDIV, I think it should report an error if the > > demoninator is undefined. >=20 > With IEEE default exceptions set, which is the only FP exception > setting V supports, dividing by zero gives +Inf/-Inf, but no exception. The fact that the program really slows down on a float divide-by-zero, means that it's almost certainly a bug if that happens because of an undefined value. Could something like that be made an option? > > FIST/FISTP (Store Integer) > > Storing (converting) an uninitialized float value to int may cause an > > exception if the value is +-inf, NaN or too large for the int size. >=20 > My understanding on x86/amd64 is that the result is a value the docs call > 'integer indefinite', which is 0x8000...0000. And on ppc the same happen= s > except you get either 0x800... or 0x7FF.... Looked at the P4 docs and it says exception, although I guess it could be masked by default. This is probably the same issue as the float divide. > > I'm not sure about that one, but since any float operation > > (add,sub,mul,div,load,store,sqrt,...) can cause an exception if one of > > the operands is NaN, inf or denormalised, >=20 > Well, as per above, V only supports IEEE exceptions masked. Same as above I guess. > > SSE > > I don't think SSE arithmetic instructions can generate any exception, s= o > > it's probably safer not to report errors on SSE arithmetic operations. >=20 > I believe SSE FP arithmetic can generate exceptions. If it couldn't,=20 > SSE would be useless as a way of doing IEEE compliant FP arithmetic. SSE does support +-inf and NaN for results, but I was under the impression that it couldn't generate exceptions or slow down the CPU when inf/NaN gets generated. This is required for computing on a vector or 2-3 values without clearing the rest of the registers. Of course, I could be wrong, so please point me to the doc if this isn't right. > Yeh, I've heard of the P4 denormalised value performance disaster=20 > phenomenon before now. Detecting this would fall more into the area > of a profiling tool though. It wouldn't be hard to do. That would certainly be very useful for everyone doing either DSP or numerical simulations. Jean-Marc |