OpenACC middle end changes

Jakub Jelinek jakub@redhat.com
Thu Dec 18 11:39:00 GMT 2014


On Thu, Dec 18, 2014 at 12:07:01PM +0100, Thomas Schwinge wrote:
> > > -	case GF_OMP_FOR_KIND_SIMD:
> > > -	  kind = " simd";
> > > -	  break;
> > > -	case GF_OMP_FOR_KIND_CILKSIMD:
> > > -	  kind = " cilksimd";
> > > -	  break;
> > >  	case GF_OMP_FOR_KIND_DISTRIBUTE:
> > >  	  kind = " distribute";
> > >  	  break;
> > >  	case GF_OMP_FOR_KIND_CILKFOR:
> > >  	  kind = " _Cilk_for";
> > >  	  break;
> > > +	case GF_OMP_FOR_KIND_OACC_LOOP:
> > > +	  kind = " oacc_loop";
> > > +	  break;
> > > +	case GF_OMP_FOR_KIND_SIMD:
> > > +	  kind = " simd";
> > > +	  break;
> > > +	case GF_OMP_FOR_KIND_CILKSIMD:
> > > +	  kind = " cilksimd";
> > > +	  break;
> > 
> > Why the reshuffling?  The result isn't alphabetically sorted
> > anyway.  I'd just add new stuff at the end ;)
> 
> It's the order in which the GF_OMP_FOR_KIND_* are defined.  At least for
> my mind ;-) that makes it very easy to grasp that all of them are
> covered.

Ok.

> > > +/* Return true if STMT is any of the OpenACC types specifically.  */
> > > +
> > > +static inline bool
> > > +is_gimple_omp_oacc_specifically (const_gimple stmt)
> > 
> > Why not is_gimple_oacc or gimple_oacc_p ?
> 
> The idea is to make it clear in the name that STMT must be an OMP one.
> Now renamed to the shorter is_gimple_omp_oacc.

Ok.

> > If you want to shift from bitmasks in the enum
> > to extra on the side bits (why?), then combined
> > for parallel is another thing.
> 
> Right, but I've now dropped (reverted) this and further gimplification
> changes.  Maybe this is material for the next stage 1, but maybe not
> useful enough.

Ack.

> Do you want me to repost the OpenACC Middle End changes patch, or would
> you be OK with reviewing the code on gomp-4_0-branch, diffing against the
> last trunk merge point, 0fcfaa33cbf333ac69cc2b01a7277e5272ff8a3d,
> r218679?

So, is what is on the gomp-4_0-branch now all that you'd like to merge to
trunk now?  Has it been tested on nvptx?  I guess we should test it with
XeonPhi offloading too to make sure it doesn't break.
And then you or together with your coworkers should write the summary
ChangeLogs (i.e. what changed compared to trunk in a single giant entry
for each ChangeLog file as opposed to many ChangeLog.gomp change entries).

	Jakub



More information about the Gcc-patches mailing list