[llvm] [Offload] Introduce offload-tblgen and initial new API implementation (PR #108413)

[Callum Fare via llvm-commits]

callumfare wrote:

> I would suggest we generate the source from tablegen, and check it in, and also have a unit testing step which generates the source again and diffs it against the copy in the local filesystem, and fails if they differ. As long as CI is running that test we'll catch the divergence.

Agreed, I think this is a good way to balance things. I'll make sure to add a test/check target to this PR so we can immediately have it covered by CI.

> Also don't call it new. This would be the... fourth? plugin revision and I think most of them are called some variant on "new".

I think it makes sense to just call this the Offload API while the existing stuff is the omptarget plugin interface (or similar), if there are no objections to that. Obviously in this PR the API doesn't come close to implementing a usable interface, but we can/should focus on getting the basics working (up to and including kernel execution) asap.

> Is it viable to develop the tablegen without the source checked in, and once it's holding together, have it replace the existing source files? Thus there is no new/old, just a transition from handwritten C++ into generated C++ which does the same thing, and we can permute the existing source code to look more like the generated output under CI.

Swapping it out when ready makes sense to me, although I'm not sure how we get there. I see the current approach being

- Implement the new API on top of the existing plugin interface. This is what this PR does. We can't simply change the existing plugins without breaking omptarget (or spending significant effort updating that code at the same time).
  - This also means for new functionality we will have to add it to the old interface, even in a hacky way, so the implementation has something to use. Seems like it would be extra effort on the old plugins.
- When the new API reaches some usable critical mass, update the plugins to implement the new API directly. Then either rewrite the plugin interface (that libomptarget uses) on top of that, or just rewrite the libomptarget code to use it directly. I'm not familiar enough with the project to say whether that's a good idea.
  - This is kind of an all-or-nothing thing where we can't really swap things out incrementally. 

> Honestly my preferred solution would just be to start this as an entirely separate interface so we don't need to deal with breaking OpenMP stuff for existing customers. That's what I wanted from `offload/` in the first place. i.e. redo the plugins as well.

This is absolutely our (Codeplay) preference, but I'd got the impression that we'd decided against this as a group. If we did this, we could create a `plugins-nextgen/offload` plugin (implementing the old interface on top of the new one), to allow us to optionally run OpenMP through the new API, but not breaking anything else. Then at some future point it could become the default path. I think this would be less of a headache than the approaches described above.

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