From: Thierry L. <thi...@in...> - 2010-03-10 09:37:52
|
Hi Gabriele, > Hi Thierry, > >> For true/false, it happens that conditions on floating point values may be >> computed by first using a comparison, and then a brtrue or brfalse. So >> inverting the branch may lead to the same problems as with branches with FP >> operands. >> > > OK, that must be why I've left it out. > In fact, I've reverted my changes, and added cases to invert brtrue and brfalse because I still think it could work. Indeed, brtrue is the exact negation of brfalse whether a previous comparison occured on floats or not. I ran the testsuite, and it passed as well as before any change: 1247 unexpected fails, but all ieee tests that did not pass after my 1st patch now pass. So I think it's ok. >> For the FP general case, wouldn't it be possible to use *.un (or not) >> versions of the branches? I'll make tests to check. >> > > Yes, if you are very careful you can change some of the conditions by > using the appropriate unordered comparisons. However you should also > verify with the mono JIT compiler if it is worth to do it: many > architectures do not have the full range of floating-point > ordered/unordered comparisons so on those architectures using them > will result in very poor native code at JIT time. After considering > all the problems I decided not to touch them because the chance of > introducing some serious regressions was fairly high and the gain was > very little. > Despite it could result in poorer native code (when generating bytecode, we are not supposed to know the final target machine), inverting conditions in conditional branches still allows to reduce bytecode size (and, for some targets, it should speed up a little), so if I can do something for float comparisons, perhaps it would be worth adding another flag which would be activated with -Os, wouldn't it? I'll make some tests, then discuss with Erven (when he's cured), and finally come back to you with another, cleaner, patch. Regards, Thierry. |