[cfe-dev] [OpenMP]: wrong threadprivate storage name in task reduction
Raúl Peñacoba via cfe-dev
cfe-dev at lists.llvm.org
Thu Mar 8 11:03:13 PST 2018
Hi,
I mean that it seems that this implementation restricts the tasks that
participate in the reduction to be defined in the same lexical scope. I
have not been able to find this restriction in the OpenMP specification.
What the spec says about this topic is:
"A list item that appears in an in_reduction clause of a task-generating
construct must appear
in a task_reduction clause of a construct corresponding to a taskgroup
region that includes
the participating task in its taskgroup set. The construct corresponding
to the innermost region
that meets this condition must specify the same reduction-identifier as
the in_reduction
clause."
I tried to compile the attached file. The compile command is:
clang -fopenmp task_red.cc
Regards,
Raúl
El 08/03/18 a las 15:30, Alexey Bataev escribió:
>
> Hi,
>
> >>> Anyway, this implementation of task reductions is not fully
> functional, as only are allowed if the task is created in the scope of
> taskgroup.
>
> What do you mean?Could you provide some more detais?
>
>
> -------------
> Best regards,
> Alexey Bataev
> 08.03.2018 7:47, Raúl Peñacoba пишет:
>>
>> Hi,
>>
>> I did some little research and I have realized that the patch I
>> attached doesn't fix the problem completely. I fixed the storage of
>> the data. When a using task reduction with vla, or a class that uses
>> omp_orig to initialize the private copies, the size of the vla and
>> omp_orig are stored in a storage using __kmpc_threadprivate_cached().
>>
>> The problem comes because, since in outline parallel function each
>> reduction has lazy_priv flag, the initialization will be done in
>> __kmpc_task_reduction_get_th_data(), called from outline task
>> function. This is done _before_storing the vla size or omp_orig, so
>> the initialization would be wrong in these cases.
>>
>> I think that if the storage is put before the
>> __kmpc_task_reduction_get_th_data() it should work.
>>
>> Anyway, this implementation of task reductions is not fully
>> functional, as only are allowed if the task is created in the scope
>> of taskgroup.
>>
>> Sorry for the mail duplicate.
>>
>> Regards,
>>
>> Raúl
>>
>> El 06/03/18 a las 16:21, Alexey Bataev escribió:
>>>
>>> Hi, thanks for the report, I'll take a look.
>>>
>>> -------------
>>> Best regards,
>>> Alexey Bataev
>>> 06.03.2018 4:25, Raúl Peñacoba via cfe-dev пишет:
>>>> Hi,
>>>>
>>>> I've noticed that clang does not work properly when using task
>>>> reductions with non-constant arrays and/or classes with omp_orig
>>>> constructor initializers.
>>>>
>>>> As reduction initialize/combine/finalize functions only receive
>>>> references to whatever should be initialized, combined..., clang
>>>> generates some additional storages to save the size of the
>>>> reduction array and a pointer to the omp_orig. That storages are
>>>> generated through __kmpc_thread_private_cached() calls in both
>>>> reduction functions and outline task function.
>>>>
>>>> The problem is that the storage used in outline task function does
>>>> not match the storage in reduction functions. This happens in
>>>> programs that have a task reduction or a taskloop reduction with
>>>> the in_reduction clause.
>>>>
>>>> To solve this i made an ugly patch that reuses the SourceLocation
>>>> of CodeGenFunction::EmitOMPTaskgroupDirective() in
>>>> CodeGenFunction::EmitOMPTaskBasedDirective() to match the storages
>>>> and make it work. Anyway, i suppose that there is a better way to
>>>> fix this.
>>>>
>>>> Index: CGStmtOpenMP.cpp
>>>> ===================================================================
>>>> --- CGStmtOpenMP.cpp (revision 326685)
>>>> +++ CGStmtOpenMP.cpp (working copy)
>>>> @@ -2713,6 +2713,8 @@
>>>> emitEmptyBoundParameters);
>>>> }
>>>>
>>>> +static SourceLocation reductionLoc;
>>>> +
>>>> void CodeGenFunction::EmitOMPTaskBasedDirective(
>>>> const OMPExecutableDirective &S, const OpenMPDirectiveKind
>>>> CapturedRegion,
>>>> const RegionCodeGenTy &BodyGen, const TaskGenTy &TaskGen,
>>>> @@ -2952,7 +2954,7 @@
>>>> // FIXME: This must removed once the runtime library is
>>>> fixed.
>>>> // Emit required threadprivate variables for
>>>> // initilizer/combiner/finalizer.
>>>> - CGF.CGM.getOpenMPRuntime().emitTaskReductionFixups(CGF,
>>>> S.getLocStart(),
>>>> + CGF.CGM.getOpenMPRuntime().emitTaskReductionFixups(CGF,
>>>> reductionLoc,
>>>> RedCG, Cnt);
>>>> }
>>>> }
>>>> @@ -3180,8 +3182,9 @@
>>>> std::advance(IRHS, 1);
>>>> }
>>>> }
>>>> + reductionLoc = S.getLocStart();
>>>> llvm::Value *ReductionDesc =
>>>> - CGF.CGM.getOpenMPRuntime().emitTaskReductionInit(CGF,
>>>> S.getLocStart(),
>>>> + CGF.CGM.getOpenMPRuntime().emitTaskReductionInit(CGF, reductionLoc,
>>>> LHSs, RHSs, Data);
>>>> const auto *VD =
>>>> cast<VarDecl>(cast<DeclRefExpr>(E)->getDecl());
>>>> CGF.EmitVarDecl(*VD);
>>>>
>>>> Regards,
>>>>
>>>> Raúl
>>>>
>>>>
>>>> http://bsc.es/disclaimer
>>>>
>>>
>>
>>
>>
>> WARNING / LEGAL TEXT: This message is intended only for the use of
>> the individual or entity to which it is addressed and may contain
>> information which is privileged, confidential, proprietary, or exempt
>> from disclosure under applicable law. If you are not the intended
>> recipient or the person responsible for delivering the message to the
>> intended recipient, you are strictly prohibited from disclosing,
>> distributing, copying, or in any way using this message. If you have
>> received this communication in error, please notify the sender and
>> destroy and delete any copies you may have received.
>>
>> http://www.bsc.es/disclaimer
>> <https://nam03.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.bsc.es%2Fdisclaimer&data=02%7C01%7C%7C2a787fae16d1409fb12808d584f2b8da%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636561100369995188&sdata=Qg460eDN4kZxnL4NIiP06MjaE85rnbyx2M%2FyVR7jif8%3D&reserved=0>
>>
>
http://bsc.es/disclaimer
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20180308/49ea6666/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: task_red.cc
Type: text/x-c++src
Size: 410 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20180308/49ea6666/attachment.cc>
More information about the cfe-dev
mailing list