[perfmon2] Avoid hardcoding the number of entries in the libpfm library with PFM_PMU_MAX

[William C. <wc...@re...>]

Hi,

I just got done analyzing a problem where papi was built with an old verion of the libpfm then it was being tested with a newer version of libpfm that had support for additional processor architectures.  In theory things should just work because papi was using the libpfm shared library.  However, in this case the papi did not recognize the newer hardware's pmu.  The problem was caused by use of the PFM_PMU_MAX enum in papi's pe_libpfm4_event.c initialization loop:

   for(i=0;i<PFM_PMU_MAX;i++) {
      memset(&pinfo,0,sizeof(pfm_pmu_info_t));
      retval=pfm_get_pmu_info(i, &pinfo);
      if (retval!=PFM_SUCCESS) {
	 continue;
      }
   ...
   }

The older libpfm that papi was built with has a smaller value for PFM_PMU_MAX than the newer libpfm on the system being tested.  Thus, the pmu entries added in the newer libpfm were not scanned by papi.

There should be a better way of doing this in libpfm.  As new pmus are added to libpfm the other code should not need to be recompiled because of a change to PFM_PMU_MAX. The following in /usr/include/perfmon/libpfm.h will also cause problems with this problem if it is used in other applications:

#define pfm_for_all_pmus(x) \
	for((x)= 0 ; (x) < PFM_PMU_MAX; (x)++)


One possible way is to use the return value from pfm_get_pmu_info() to determine whether a loop is at the end of the valid pfm_pmu_t range. Any thoughts or comments on this?

-Will