Hi!
On Wed, 12 Nov 2014 11:06:26 +0100, Jakub Jelinek <ja...@redhat.com> 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
