Hi! On Wed, 12 Nov 2014 11:06:26 +0100, Jakub Jelinek <[email protected]> wrote: > On Tue, Nov 11, 2014 at 01:53:23PM +0000, Julian Brown wrote: > > @@ -1181,6 +1197,7 @@ initialize_env (void) > > gomp_global_icv.thread_limit_var > > = thread_limit_var > INT_MAX ? UINT_MAX : thread_limit_var; > > } > > + parse_int ("GCC_ACC_NOTIFY", &goacc_notify_var, true); > > I would have expected GACC_NOTIFY name instead (or GOACC_NOTIFY) > to match GOMP_SPINCOUNT and similar env vars.
GOACC_NOTIFY was a first implementation for an immediate need, but I've
always had in the back of my head the idea to generalize this. How about
GOMP_DEBUG, and this can then be set to comma-separated list of "classes"
of debugging information?
> > + gomp_notify ("%s: mapnum=%zd, hostaddrs=%p, sizes=%p, kinds=%p\n",
> > + __FUNCTION__, mapnum, hostaddrs, sizes, kinds);
>
> Isn't such debugging too costly? Perhaps either enable it only in
> debugging builds, or at least guard with (perhaps in a gomp_notify macro)
> with
> if (__builtin_expect (goacc_notify_var, 0))
> (gomp_notify) (__VA_ARGS__)
> ? I'd think doing it in debugging builds only should be sufficient.
I think, users may occasionally wish to see such "debugging" information,
but certainly, guarding it with __builtin_expect is a good thing to do.
How about having an enum gomp_debug, defining several "classes" of
debugging information ("device" (scanning), "mem" (mapping setup),
"offload" (kernel launches), and so on -- not all to be added right now,
of course), and make that the first parameter to gomp_debug? Certainly
that can't be in "hot" code paths (too much output), and for "non-hot"
code paths, I don't think the gomp_debug_var comparison matters, compared
to the other code executing nearby.
Grüße,
Thomas
signature.asc
Description: PGP signature
