On Tue, Dec 12, 2023 at 04:17:47PM +0000, Andrew Stubbs wrote:
> On 12/12/2023 10:05, Tobias Burnus wrote:
> > Hi Andrew,
> >
> > On 11.12.23 18:04, Andrew Stubbs wrote:
> > > This creates a new predefined allocator as a shortcut for using pinned
> > > memory with OpenMP. The name uses the OpenMP extension space and is
> > > intended to be consistent with other OpenMP implementations currently in
> > > development.
> >
> > Discussed this with Jakub - and 9 does not permit to have a contiguous
> > range of numbers if OpenMP ever extends this,
> >
> > Thus, maybe start the ompx_ with 100.
>
> These numbers are not defined in any standard, are they?
omp_null_allocator is (it has to be zero), the others don't have value
specified in the OpenMP standard, but it is an ABI thing.
LLVM has
omp_null_allocator = 0,
omp_default_mem_alloc = 1,
omp_large_cap_mem_alloc = 2,
omp_const_mem_alloc = 3,
omp_high_bw_mem_alloc = 4,
omp_low_lat_mem_alloc = 5,
omp_cgroup_mem_alloc = 6,
omp_pteam_mem_alloc = 7,
omp_thread_mem_alloc = 8,
llvm_omp_target_host_mem_alloc = 100,
llvm_omp_target_shared_mem_alloc = 101,
llvm_omp_target_device_mem_alloc = 102,
KMP_ALLOCATOR_MAX_HANDLE = UINTPTR_MAX
and I think it is desirable to be ABI compatible here with the standard
values. So, I think it is better to have one range for the standard ones
(same values as other implementations) and another range for the extensions
(and given that LLVM uses 100-102 range, perhaps pick a different one, 200
or 150). And then 2 tables, one for the standard range, one for the
extensions.
Jakub
