[Openmp-commits] [PATCH] D68310: Introduce an interface for target_impl that supports default implementations

[Jon Chesterfield via Phabricator via Openmp-commits]

JonChesterfield added a comment.

> A header file per function, or set of function that belong together, was what I meant.

Cool. So something like kmpc_atomics.h in common, that can be `#included` or can be ignored based on the target's desires.

> I'm still unsure how much "target specific code" we want to provide as a default without it becoming completely target independent.

The "target specific" idea can be refined a little. I think we have the following categories:

- Operations that have to be done in asm or with target builtins (e.g. lanemask)
- Operations that can be done in C, but the target wants to use target builtins or asm anyway (e.g. pack)
- Operations that are done in C, but different architectures want different C (don't have any yet)

> If there is code to be shared now, I mean with hopefully soon two targets, we could just call it common code. Once we get to the situation with >2 targets and not all but some share some code, we can reevaluate and determine the best solution for the actual use case at hand. I'm not strictly against templates or overloading but these do not solve all problems but basically only the ones we do not face yet. Designing something for a future use case is generally to be avoided (IMO).

That's fair. The 'default' I have in mind is essentially what amdgcn uses, as it could be used by other architectures without changes. However until such point as a third architecture is imminent (and indeed we don't have two yet), it's difficult to reliably distinguish common from target specific.

I'll leave this diff open for a while to see if it attracts more comments.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D68310/new/

https://reviews.llvm.org/D68310