# RFC for omp.target construct

**URL:** <https://discourse.llvm.org/t/rfc-for-omp-target-construct/3307>\
**Category:** MLIR\
**Created:** [April 21, 2021, 2:43pm UTC](https://discourse.llvm.org/t/rfc-for-omp-target-construct/3307 "2021-04-21T14:43:19Z")\
**Posts on this page:** 1\
**Showing post:** 14

<div class="post-metadata">

**Author:** ![clementval](https://sea1.discourse-cdn.com/flex021/user_avatar/discourse.llvm.org/clementval/32/237_2.png) [@clementval](https://discourse.llvm.org/u/clementval)\
**Post date:** [July 1, 2021, 2:11pm UTC](https://discourse.llvm.org/t/rfc-for-omp-target-construct/3307/14 "2021-07-01T14:11:09Z")

</div>

Yes, I’m almost done with that. The idea is to extract the information we need for the runtime when we still have information about the original FIR type and we know the transformation applied. In the end the operands are normalized to be LLVM types that the translation understand and can map to the runtime.  
The same conversion for memref is done here as an example: [⚙ D102170 [mlir][openacc] Conversion of data operand to LLVM IR dialect](https://reviews.llvm.org/D102170)

Since the map clause is required on target data directives (enter/exit and the region one). I would not handle this as a separate operation. It should be one operation where map variables are operands devided into segments. If you model your operation in a similar way than acc.enter\_data, acc.exit\_data and acc.data you have almost no work to do for the conversion and translation as you can reuse the code directly. We might need to put it in a better place and generalize some part but the translation should not differ that much besides the flag to apply to each operands.

---

_[View the full topic](https://discourse.llvm.org/t/rfc-for-omp-target-construct/3307)._