[Open64-devel] Barriers inserted by Inline

[Christophe L. <chr...@st...>]

[repost, since it seems this email didn't reach the list]

Hi all,

I am studying an issue with the __restrict qualifier in C, with our port
of Open64.

Consider the following sample code:
=================================================================
#include <stdio.h>

int global = 10;

static inline void foo(int* __restrict ptr)
{
     *ptr = *ptr + 1;
}

int main()
{
     int* mptr = &global;

     *mptr = 0;
     foo(&global);

     if (global != 1)
	printf ("FAILURE : expected %d, found %d\n", 1, global) ;
     else puts("SUCCESS") ;

     return 0;
}
=================================================================

When compiled in -O2, this code fails.

Adding -INLINE:restrict makes the code run OK, but the generated code is
quite slow. (It is much better without __restrict)

In presence of the __restrict qualifier, the inliner inserts named
forward and backward barriers (ipo_inline.cxx:Generate_Barriers()).

Later, these barriers are processed in be/opt/opt_alias_analysis.cxx.
In Compute_barrier_mu_chi(), in the code that handles the named
barriers, I cannot see the restrictions:
	if (aux_pt->Local() &&
	    (psym->St() && !ST_is_shared_auto(*psym->St())) &&
	    (psym->St() && ST_sclass(psym->St()) != SCLASS_FORMAL_REF))
	  continue;

while they are present in the code that handles the unnamed barriers.

Given the semantics of barriers, as detailed in the same file, I don't
understand why?


Also, I can see that the "is_mp_barrier" parameter of
Compute_barrier_mu_chi() is true for opr != OPR_DEALLOCA. Which means
it's true with the sample code above. As our compiler does not support
MP, does this really make sense?


Thanks,

Christophe.