[Mlir-commits] [mlir] [OpenMP][MLIR] Add omp.distribute op to the OMP dialect (PR #67720)

[Jan Leyonberg]

jsjodin wrote:

> > > Since distribute is always specified on a loop, it might be good to retain that relation in the IR. You could do the following. Here the `omp.canonical_loop` is either the loop to which the distribute construct is applied in the source or could be one that is generated after a loop transformation construct.
> > > ```
> > > omp.distribute {parallel do simd} {
> > >   omp.canonical_loop {
> > >   }
> > > }
> > > ```
> > 
> > 
> > I'm wondering if it will be difficult to represent the various clauses that could be added to the different directives if we use this representation?
> 
> For clauses, all supported clauses will have to be added and the verifier should be used to ensure that only the permitted ones are supported.

Does that mean that clauses that are associated with omp.parallel would be duplicated in omp.distribute? I would be hesitant to duplicate things if it is possible to compose things instead.

> 
> > I am also wondering if there is additional ops other than omp.canonical_loop, then it may still require some traversal of the code.
> 
> I did not understand this point.

I misunderstood the restrictions of distribute, so you can ignore this.

> 
> For suggesting the above representation, I was concerned with three points:
> 
> 1. Composite constructs : `!$omp do simd` is a composite construct and not a combined construct. Hence we should either model thatas a separate operation ( (omp.wsloop_simd) or have these as attributes.

I'm not sure it is possible to have omp.wsloop_simd if there is a loop transform that could change which loop the simd operates on, so it would have to be an attribute or wrapper op.

> 2. While `omp.wsloop` and `omp.simd` works on loops `omp.parallel` does not and having that in between constructs would prevent `omp.distribute` from working directly on a loop or a loop-related construct.
> 3. In source code, distribute is always specified on a loop.

Yes, I think these are valid points. Would it be enough for a verifier to check that only the allowed ops like parallel and simd (in addition to the omp.wsloop) are present inside of a omp.distribute instead of encoding it directly in the IR as attributes? 


https://github.com/llvm/llvm-project/pull/67720