This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug middle-end/71373] Handle more OMP_CLAUSE_* in nested function decomposition


https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71373

Thomas Schwinge <tschwinge at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |SUSPENDED
           Assignee|unassigned at gcc dot gnu.org      |tschwinge at gcc dot gnu.org

--- Comment #7 from Thomas Schwinge <tschwinge at gcc dot gnu.org> ---
Created attachment 38681
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38681&action=edit
Document missing OMP_CLAUSE_* in gcc/tree-nested.c

(In reply to Jakub Jelinek from comment #6)
> OMP_CLAUSE_UNIFORM
> OMP_CLAUSE_INBRANCH
> OMP_CLAUSE_NOTINBRANCH
> 
> The above 3 clauses are only allowed in the declare simd directive, so
> nothing tree-nested.c sees.
> 
> OMP_CLAUSE__LOOPTEMP_
> OMP_CLAUSE__SIMDUID_

(Also OMP_CLAUSE__GRIDDIM_.)

> These clauses are only added during omp lowering, tree-nested happens before
> that.
> 
> OMP_CLAUSE_FOR
> OMP_CLAUSE_PARALLEL
> OMP_CLAUSE_SECTIONS
> OMP_CLAUSE_TASKGROUP
> 
> These clauses are only allowed on cancel and cancellation point directives,
> which are at this point already lowered into a function call with numerical
> value.

> There is gcc_unreachable, IMHO no need to list them explicitly

It is a good thing in my opinion: the next curious reader of this code doesn't
have to wonder why some OMP_CLAUSE_* are missing here.

> and doing the
> same thing as the default, I'm afraid gcc is unable to optimize that.

Being curious about that, I'm confirming that using the patch I'm attaching. 
That's surprising to me!  The code size doesn't improve much (0.42 % in my
case), but I would have expected it to stay the same.  Can you tell off-hand
where I would have to look, to teach GCC how to optimize such constructs? 
There should be relatively common, I would think?  (Setting the PR to
"suspended" until that is resolved.)

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]