On Fri, 9 Dec 2016, Cesar Philippidis wrote:
> > Normally all offloaded code has either "omp declare target" (most
> > functions) or
> > "omp target entrypoint" (only toplevel offloaded code). This used to
> > include
> > OpenACC functions: they would have "oacc fnattrib" _in_ _addition_ to those
> > attributes, not _instead_ of them! If something related to a recent OpenACC
> > patch adds "oacc fnattrib" without at the same time adding "omp declare
> > target",
> > it's probable that other places in the compiler may break, not just IPA ICF.
> >
> > The explanation and the patch are written as if "oacc fnattrib" can appear
> > without "omp declare target" -- ttbomk this could never happen before.
> >
> > Can this please be cleared up?
>
> It was more so to point out that there were cases where OpenACC
> offloaded regions may not have omp target attributes. Referring back to
> case 2 in the original email:
>
> 2. Nested offloaded regions inside 'omp declare target' functions do
> not have 'omp target entrypoint' attributes either.
>
> See the logic in omp-low.c:create_omp_child_function.
Let's see:
> if (cgraph_node::get_create (decl)->offloadable
> && !lookup_attribute ("omp declare target",
> DECL_ATTRIBUTES (current_function_decl)))
> {
> const char *target_attr = (is_gimple_omp_offloaded (ctx->stmt)
> ? "omp target entrypoint"
> : "omp declare target");
> DECL_ATTRIBUTES (decl)
> = tree_cons (get_identifier (target_attr),
> NULL_TREE, DECL_ATTRIBUTES (decl));
> }
So, like I said -- offloaded functions have either "omp target entrypoint" or
"omp declare function". Either of those are caught by the _existing_ "omp "
prefix check in IPA ICF.
It doesn't matter that nested entrypoints might not have "omp target entrypoint"
on them, because even if they have just "omp declare target" it's still subject
to that ICF blacklist.
My objection still stands -- if you have "oacc fnattr" functions that have
neither of those attributes, that doesn't seem right.
Alexander
