On Mon, 30 Nov 2009 11:07:40 -0300, Lisandro Dalcin <[email protected]> wrote:
Indeed. Cython (used in petsc4py) uses these definitions everywhere.
I think they are just clutter unless it's a "hot" conditional or used so pervasively that it changes code size (CHKERRQ). But they are certainly valuable when used appropriately.
IIRC, Intel compilers do support __builtin_expect, too.
The Sun compilers do as well so I added a configure check, created PetscLikely/PetscUnlikely macros, and put this into CHKERRQ. http://petsc.cs.iit.edu/petsc/petsc-dev/rev/51e933be84ca
A big +1 from my side. This will alleviate (at least with gcc and icc) some Matt's concerns about miss-predictions we discussed long ago. At that time, I was asking for optimized builds
Note that it requires --with-errorchecking=0 which is not a normal part of an optimized build.
to "#define CHKERRQ(ierr) if (ierr) return ierr;" instead of empty.
So with error handling, we get call SomePetscFunction test eax,eax je ErrorPathForFirstLine ;; shuffle registers to call the next function ;; ... call AnotherFunction test eax,eax je ErrorPathForSecondLine With no error checking, the test, je stuff would be completely gone, i.e. call SomePetscFunction ;; shuffle registers to call the next function ;; ... call AnotherFunction test eax,eax je ErrorPathForSecondLine which actually makes the non-error path smaller. With your suggestion, the non-error path will look exactly as above (the jump address would be constant). The error path would usually be on the same page as the rest of the function so it would have to come to L2 [1], but it should almost never make it to L1I so I would expect there is no measurable difference between calling PetscError and your simple return. Without a benchmark showing differently, I wouldn't be in favor of supporting that option. Jed [1] -freorder-blocks-and-partition might be able to keep it out of L2 as well.