[PATCH] [OPENMP] Do not emit references to original variables in 'private' clause.

[Bataev, Alexey]

John, this patch tries to avoid generation of pointers to private 
captures. But for tasks we need them.
CapturedStmt is built in Sema, while kmp_task_t (used in proxy function 
as argument) is generated only in codegen.  That's the main issue. 
Currently I don't see a solution how to make implicitly outlined 
function, built from CapturedStmt, and that does not know anything about 
this kmp_task_t type, to use this kmp_task_t. Currently the only way is 
to use this shareds structure with pointers manually remapped to private 
copies.
But I'll try to investigate this situation a little bit deeper, maybe 
I'll find some better solution.

Best regards,
Alexey Bataev
=============
Software Engineer
Intel Compiler Team

19.05.2015 21:21, John McCall пишет:
> Okay, thank you.  What you're saying is that the shareds structure contains a pointer to every captured variable, and those pointers are normally initialized by taking the address of the original variable, but since private captures are allocated separately their address must be initialized separately.  That all makes sense to me.
>
> What I'm not clear on is why the shareds structure needs to contain pointers to the private captures at all.  It looks to me like that's purely an artifact of our CapturedStmt code generation, where it only expects to receive a pointer to the shareds structure.  The actual task function passed to kmp_omp_task_alloc takes a pointer to the task structure, which is where the private variables are actually allocated, and we currently just make that a proxy function that drills down to the shareds structure so that we can satisfy CapturedStmt.
>
> It seems to me that, if we can recognize that private captures need different initialization, we should also be able to recognize that they don't need an actual field in the shareds structure, and code-generation can just directly use their address in the task.  Does that not work?  Is the current formulation necessary for consistency in some way?
>
>
> http://reviews.llvm.org/D9550
>
> EMAIL PREFERENCES
>    http://reviews.llvm.org/settings/panel/emailpreferences/
>
>