Re: [OpenACC 7/11] execution model

[Nathan Sidwell <nathan at acm dot org>]

On 10/22/15 05:23, Jakub Jelinek wrote:
> On Wed, Oct 21, 2015 at 03:42:26PM -0400, Nathan Sidwell wrote:
> > +/*  Flags for an OpenACC loop.  */
> > +
> > +enum oacc_loop_flags
> > +  {
>
> Weird formatting.  I see either

Blame emacs (I thought  it was configured for GNU formatting ...)


> > +      expr = build2 (TRUNC_MOD_EXPR, ivar_type, ivar,
> > +		     fold_convert (ivar_type, collapse->iters));
> > +      expr = build2 (MULT_EXPR, diff_type, fold_convert (diff_type, expr),
> > +		     collapse->step);
> > +      expr = build2 (plus_code, iter_type, collapse->base,
> > +		     fold_convert (plus_type, expr));
>
> Shouldn't these be fold_build2 instead?

I don't think fold_build2 makes a difference here, as (at least) one operand is 
 a variable?

> > +/* FORK and JOIN mark the points at which OpenACC partitioned
> > +   execution is entered or exited.  They take an INTEGER_CST argument,
> > +   indicating the axis of forking or joining and return nothing.  */
> > +#define IFN_UNIQUE_OACC_FORK 1
> > +#define IFN_UNIQUE_OACC_JOIN 2
> > +/* HEAD_MARK and TAIL_MARK are used to demark the sequence entering or
> > +   leaving partitioned execution.  */
> > +#define IFN_UNIQUE_OACC_HEAD_MARK 3
> > +#define IFN_UNIQUE_OACC_TAIL_MARK 4
>
> Shouldn't these be in an enum, to make debugging easier?

internal-fn.def can be included multiple times in one file (probably only 
internal-fn.c).  Thus an enum would either need to go somewhere else (and I'd 
like to keep it close to the ifn def), or need to be protected in some manner. 
Hence I went with #defs, which are safe to duplicate.  Any thoughts on how to 
resolve that contention?

nathan