[Patch] OpenMP: C/C++ parse 'omp allocate'

Tobias Burnus tobias@codesourcery.com
Wed Dec 9 11:20:52 GMT 2020


On 08.12.20 18:56, Jakub Jelinek wrote:
> On Mon, Nov 23, 2020 at 03:50:33PM +0100, Tobias Burnus wrote:
>> Given that (at least for C/C++) there is some initial support for
>> OpenMP 5.0's allocators, it is likely that users will try it.
> Sadly at least the current implementation doesn't offer much benefits;
> I meant to add e.g. HBM support through dlopening of the memkind library,
> but I haven't found a box with hw I could test it on.

I am not sure that there is a big benefit for most of the allocation
options – well, maybe in theory or for cluster OpenMP solutions with
slow interconnect or maybe for those SGI Altrix systems with lots of
threads.

The largest effect should be there for offloading and unified-shared
memory systems, where pinning seems to be essential for good performance.

> I guess your patch is ok, but I should fine time to implement at least
> the rest of the restrictions; in particular e.g.:
> ...
> While the patch tests for C that the allocator has the right type, for C++
> (for obvious reasons) it isn't checked, so we need the checking there later
> from the attributes or so, at least if it is dependent.

For 'allocate' attribute, it is checked in cp/semantics.c's
finish_omp_clauses; I think it could be done there as well. – Once, the
'sorry' is either removed or moved to cp/semantics.c.

> For automatic variables, we likely need to handle it during gimplification,
That's outside of this patch, but I fear what we will need to do for
Fortran with allocatable components.
> Ok, thanks

Thanks for the review. Now committed as
r11-5879-gaa0432005f36f6ac51dc9dcecb717fe739d39b88.

Tobias

-----------------
Mentor Graphics (Deutschland) GmbH, Arnulfstraße 201, 80634 München / Germany
Registergericht München HRB 106955, Geschäftsführer: Thomas Heurung, Alexander Walter


More information about the Gcc-patches mailing list